Wayne Allen's Weblog

New Article: Agile: Story Completion Problems

Going the Extra Mile – Why Bother?

Having recently been involved with a team that was being exhorted to “step up” and “go the extra mile” I noticed a range of responses from “lets go” to “why bother” to “I don’t think so”. After thinking about the response I identified several personal factors:

1) Internal motivation: some people are just go getters, you love to have them on your team, but sometimes they are seen as little puppies by other members of the team because they are perceived as being overly eager to please. Motivating this type of person is trivial.

2) Internal ambivalence: some people just don't have that drive. "Programming as a job" is an attitude that some in our industry have. These people do a good job while they are at work, but when they are not at work – they aren’t. Motivating this type of person is more difficult since your have to convince them that the extra hours are worth it to them. The typical example for internal ambivalence is the programmer who don’t read technical material, go to conferences or training. They expect to pick up everything they need to know between 9 and 5.

3) External personal distraction: there are those who may have the internal drive, but because of various personal/external reasons choose to place other priorities in front of work. Motivating this person is not likely to succeed without significant effort because they have consciously prioritized their work life at a lower level. An example here is the developer who’s wife just had twins and is bed ridden. Attempting to get this person to spend more time at work boarders on malfeasance.

There are also a couple of factors the motivator brings to the table:

1) Trustworthiness: in several jobs I have seen otherwise motivated individuals who don't respond to motivators because the individual has determined that the motivator is not trustworthy. Thus any promise in the world will not help because the individual doesn't believe the messenger.

2) Disagreement: Closely related to trustworthiness is when the individual doesn't agree with the path the motivator is proposing. This one is trickier since this could just be resistance to change.

3) Approach: here the individual is not being motivated correctly, the carrot is offensive, or the individual is just not interested in that particular carrot. Typically money is used as a motivator, but money is not equally important to everyone. A great example here is the “employee of the month” award – I bet you can’t find developers who are motivated by this kind of reward.

Which kinds of motivating factors have you seen work for or against the desired outcome?

Why We Love Lazy Programmers

At one time our build and deploy process was full of manual steps and could take 1-2 days to put a build into the QA and Dev environments. Using tools like nAnt we improved the build and deploy time to 1-2 hours with most of the automation on the build side. Later one developer got tired of manually deploying and created some deploy scripts. Now deployment to any of the 5 environments (development, testing, staging, demo, production) is a single command line taking 1-10 minutes depending on whether a full build is required or not.

The overall investment was probably about 2 weeks of development time over several months. So we easily paid back the cost in 15 deployments. Not to mention the fact that we deploy all the time now that it is easy, resulting in our integration problems almost going away.

What are your lazy programmer success stories?

Ward Takes On Microsoft

From Wards page on c2.com:

As of December, 2003, I've taken a position at Microsoft with the title Architect. I'll be working with a group I have consulted to this last year while producing http://msdn.com/patterns. I know that some authors here have no good will for the company. Please remember I will remain the same person. I also invite TipsForWardAtMicrosoft.

Having had some personal interaction with Ward in the last year my first question (along with everyone elses I'm sure) was “why?”. Looking closer at Wards wiki page revealed that he worked for IBM Consulting somewhat recently where he answers the same question. From WardAtIbm:

Why would I quit a cool job working for myself to join IBM?

Big Clients. It's that simple. Big companies are going to take Smalltalk to the next level. I wanted to be a part of it. But big companies don't hire little consulting outfits to help them make big decisions.

I was also spending too much time fooling with my web server and needed something really challenging to pull me away from it. And they got to me first. And they made me a nice offer...

With this explanation and my personal experience of how Ward makes decisions I know he didn't do this on a lark. I also understand the need for new challenges from time to time. I certianly need to jar myself from my ruts on ocasion.

Good luck to you Ward, hope we still see you at XPDX now and again.

Agile Q&A: Missing Features/Requirements

Given the 3 part agile team of customer, QA, and development, what should we do when a feature the customer wanted is not implemented, or is incorrectly implemented at the end of the iteration?

Q: Why wasn't the missing feature caught in a customer test?

A: Customer/QA/Dev communications are not happening. I.e. the customer discussed a feature with a developer without QA present, or notified. Use a simple durable communications form such as a wiki to record decisions about a story.

Q: Who takes responsibility for ensuring requirements discussed between the customer and development are communicated to QA.

A: Ideally the customer should since QA is the customer proxy, however, the developer has some responsibility to inform QA about the currently available features. Once again a wiki can help this communications flow. Additionally the customer could add FIT tests that should start failing and start another communications flow.

Q: How do you resolve adding new features during the iteration?

A: If the new feature can fit within the current iteration (as established via a conversation with dev & QA) then do it. Don’t worry about the old nature which says control scope first, worry about user satisfaction second. If the feature cannot be added without jeopardizing the currently selected stories for the iteration the customer has 2 choices. 1) leave the feature to a future iteration or 2) take something of equivalent effort out of the current iteration.

Q: How do you deal with a story that has missing features once the iteration is completed?

A: Essentially this is a new story. However, based on the size/scope it may fall into the category of bug/enhancement in which case it should be bundled together into a story with other small changes. No matter what you do –  do not succumb to the temptation to change the iteration end date to accommodate adding the feature. This will only cause further problems down the line. Iterations are your scheduling time boxes, not release schedules.

This assumes you had customer tests that told you the feature wasn’t complete. If it was a surprise that the feature was missing take a look at the first question above.

Pixel Perfect Web Design

It can't be done.

I keep running into designers, users and even developers who think they can design a layout that will be exactly the same on everyone's computers.

Web browsers are not the same as Photoshop!

Lets count the ways:

1. Fonts - each user of your site could have a different version of the font you specified, or maybe they don't have it at all, or they are ignoring your font specifications altogether.
2. Margins - browsers render margins differently, sometimes versions of the same browser render margins differently.
3. Color - browsers render colors differently, just look at some of the trouble trying to make an IE/NN page where image colors match the browser specified color, especially outside of the “safe” range.
4. Dpi - Might be 72, 96 or something else.

These are just the areas I could think of right now, I know there are others.

So my advice - don't even try. And if someone asks you to, make sure you charge them a lot of money and set the due date to Jan 15, 2048.

Why Is So Much Code So Bad?

I've been in the position to read a lot of code written by many different developers. And most of it is terrible.

When I first noticed this I figured I was being too hard on the developers, they didn't have as much experience as I did, they didn't get any training, nobody else on the team was capable of mentoring them, etc.

But after many years of seeing the same stuff I just have to assume that big ball of mud procedural coding is the state of the practice for the average developer, even those with many years of experience.

Why is this? And more important, how can we change this?

Personally I find the best way to improved someone's coding ability is to pair with them extensively on a real project (hands on mentoring). But this only works if the project team is really small. I can't pair extensively with everyone on an 8 person team.

Training seems like a possible solution, although it seems to have limited usefulness.

Ultimately I think it comes down to an individual's drive and willingness to learn/change. All of the really good programmers I've met are self taught.

Is this something you've noticed in your workplace? What are you doing about it?

What Makes A "Good" Company Different From Any Other?

I haven't had that many jobs in my life, but as a contractor for 13 years I've been in numerous companies and talked to lots of people about how much they liked their jobs. Believe it or not, the biggest reason I've found for job dissatisfaction is management.

Almost everyone is mostly happy with their co-workers, work challenges, pay, benefits etc. Almost always, they complain about their supervisors, the executives, and especially the investment board.

I'm not sure it is totally management, since many people (myself included) have worked for really good managers. I think there is also some correlation to the number of levels of management.

At one time I worked for a “good” company with about 100 employees. We enjoyed a 90%+ retention rate before the dotcom bubble peaked. There was 1 level of management between me (the worker bee) and the CEO, some people had 2 levels. This company was sold to a much larger company for a lot of money (really good timing on the owner's part). I now had 8 levels of management between me and the CEO and the retention rate dropped to about 50% as all the senior people found different jobs, rather than working for the new company. This could be a result of the new company not understanding the services of the company they bought and thus angering those who did. Or it could have been the transition from personal management to impersonal management.

Another company had 4 levels of management between the worker and the CEO and the retention rate was about 50% again. In this case the investment board couldn't seem to make up its mind about where the company was going. They staffed up, called for a RIF and then soon after an across the board 10% pay cut followed by ousting the CEO and bringing in a new one, then setting goals based on promises made by people who were no longer with the company. Here one could argue that the quality of leadership was a larger factor than the number of management levels. I might argue that there is a correlation still.

How about you? Do you work in a good company with many levels of management? Or only a few? Or do you like many others have lots of management and everyone complains about them?