| dallaway.com - Writing - Release Hell |
Richard Dallaway, June 2004
All the developers I know hate "last minute release hell". This is the frenzy of activity that hits when the time comes to release or ship the thing you've been working on. A bunch of obscure or dumb problems show themselves, and panic ensues.
I have no magic bullets to stop this problem from ever occurring, but on a recent project I was struck by the blindingly obvious, and I thought I'd share.
It's bad for everyone. If you're coding, you probably have a manager, and they might have made promises to other people, marketing have got things booked, and customers have been told...there's a lot of pressure on, which makes for a horrible time, full of grumpy individuals, leading you to day-dream about quitting your job or the software business completely.
My recent experience of this sort of hell lasted for about two days. The project was going fairly well, and I was wondering how we'd got ourselves into this position, and that's when the obvious presented itself:
The part of the code that was causing us pain was the part with the fewest unit tests.
This might be an obvious statement for you, and indeed it was for me. However, despite knowing this information at some level, it was the first time it had become an "observed fact" for me, affecting this particular release beyond all the other factors that could be to blame.
So why didn't we have these unit tests? Because it was an area of code that was hard to test. Or rather it was perceived to be hard to test. I've since gone back and created some tests. It took me about 30 minutes to think about how to create meaningful tests, and about two hours to implement the tests. In doing so I had to change the code to make it more testable, which almost always leads to a better design. More importantly, code that was once tainted as being "fragile" and "I don't want to touch that again", is now restored to first class "no worries" code.
If we'd put those 2.5 hours in at the beginning, we would have saved two days of headache. If you have any doubts about the utility of unit testing, let me make it simple: they are worth doing.
You barely have time to eat lunch, so how are you going to write enough tests? Your boss wants the project done by such-and-such a date, and you have to respect that.
There might be little you can do about this, but there's one thing you can try. Unfortunately, it's one of the other things software developers hate...
"When will it be done?" "How long will it take?"
Many of the developers I know don't like to answer these questions. The truth is that it'll be done once it's done, because that's the only way to know for sure what all the problems are. Still the question will be asked, and it turns out to be a good thing.
To understand why, recall that scope has a huge effect on a project. Remove functionality, and you can probably get the job done on time. This is where estimation comes into it, because the very best way to help your boss make scope decisions is to tell them how long things take to do.
If you hate giving time estimates it might be because you'll get it wrong. Well, you will get it wrong because predicting the future is pretty hard. That's why it's called an "estimate". There's a big plus side to estimation: by giving estimates you get to include the stuff you never have time for, namely unit testing, cleaning up the crud you left around last time (a.k.a. refactoring), profiling and reading articles about development.
The point is that you're a professional, and so to do a professional job, you ought to allow for testing and all the other things you need to do. It's like a builder needing time to mix cement rather than just skipping ahead to balancing bricks to make a wall. Include these things in your estimates.
I don't know the best way to estimate. Here's one way I've tried, and it seems to be OK:
Estimate in ideal programming hours. That's the number of hours to do something if there are no disruptions such as deleting email, going to meetings and being given "priority one" tasks that are more "priority one" than all the other "priority one" tasks you're working on.
Write down the name of some chunk of functionality and list the things you'll need to do to implement it. Then take a stab at how long it'd take to finish. Three hours for this, an hour here, that's a 14 hour job, and so on.
With this estimate you can let people know how long it'd take to get something done, and with this information they can make an informed decision about which bits of the project they really do want done and which can wait. Remember, though, to turn hours into a date you need to know how many working hours you put into a project. If you spend half of your working day actually working on these things, I suspect you're doing well. Record the hours you do (at the end of the day, just make a quick note to yourself) and over time you'll get better at doing this, but you'll never ever get it right all the time.So don't stress about it.
You don't have to be trapped in release hell. Control your time by giving estimates.You'll end up doing a better job, because you'll have time to include things like unit testing, and you'll give your team more confidence in your software releases, making your life less stressful.
First version June 2004. This version: $Id: index.html,v 1.1 2004/07/04 10:19:43 richard Exp $