Friday, April 18, 2008

Let there be change

What is the most common complaint during the execution of a software project?

Software Developer: How am I supposed to ever finish this $@#&ing project if the $@#&ing customer changes their $@#&ing mind every $@#&ing day?...$@#&!

I'm no stranger to that, believe me, I understand completely. There is nothing so frustrating as working on something for a long time and struggling to perfect it, only to be told that this wasn't really what they were asking for and to be handed another checklist of modifications ("you'll be fine, really, there isn't that much to it").

So how do should we mitigate it? Make the customer commit before hand to their feature list? Demand a salary increase for every late change? Make them sign the spec at the start? In blood?

Hold on, hold on, those are great ideas (note: those are not great ideas), but I think what this problem is really asking for is a perspective change. Yes, we need to keep the change list under control, but there are plenty of tools, techniques, and methodologies that already address that issue. What I want to talk about is the attitude. We shouldn't get angry when the change list starts to grow, we should get excited.

Reader: Bullshit. You are pandering to the customers, possibly to increase the frequency of your consulting offers, and I am not reading any more of this drivel.

Man, I'm glad that guy's gone. If you're still here, you're probably a reasonable reader who wants to hear me out and won't send me hate mail.

If you're getting requests for changes, it's usually not because you've done bad work (unless you've done bad work, and then you have no-one to blame but yourself). It's usually because the customer has seen the current system in action, and has an idea for a way to make it even better, and if this project is going to be anything that is going to be distributed outside your office, if this is going to be a public-facing piece of software that people will pay you to use, you're going to want that end result to be as close to "freakin' amazing" as you can possibly push it.

That's why you should be excited at the proposition of improvements; it means that the people on your team are still having ideas about how to get better, and as long as you can keep that fire-hose of new concepts going you're moving forward. So by all means release early and often, certainly prioritize those changes and work the most important ones first, definitely be on guard against making the system any more complicated than it needs to be, but for God's sake be happy that people are asking you to do more; you'll be reaping the benefits when the subscribers start rolling in.

2 comments:

Anonymous said...

I encourage changes. Most users don't know what they want and can't ask for anything close to what they will eventually want so we must encourage those changes.

The problem is, and I think where the root of much of the anger from this issue, is that we are forced to use metrics that discourage change. Change has become synonymous with 'more work' or 'extra unpaid hours'.

'If we make this change, it won't be ready for another 8 months.'
'We need it in 2, during the time you originally said it would be done'
'You changed your mind, you can get the previous version in 2 months or maybe the other version in 8'
'We must deliver value to our customers now, so we'll polish up what you have and then change it later'

That's the logic that can make me cringe.

To me, changes show that they are understanding what they are getting and that they are wanting the software to be able to control the way that they do things.

There's too many people that want the software to tell them how to do their jobs and they somehow believe they are using that black box piece of crud off the shelf software to do that. Or, they overpay for extremely complex software but only use what a remedial black box would bring.

Anonymous said...

Speaking as a "client" who also does light coding, your point is dead on. The best changes are the result of working with the application, seeing how it fits the problem you need to solve, and evolving the application as needed.

In addition to the comment about the meta issues around what use for metrics, for me the real issue is how to get the client and the programmer to define change the same way. And to force the client to provide plenty of lead time for notification about changes, forcing them to think pro-actively so the programmer(s) waste as little time as possible.