The Rush
Posted by Uncle Bob on 06/26/2009
There’s nothing like the feeling of achievement when you get a complex software system working. It’s the feeling of the hunter making a hard fought kill. By the sheer power of your intellect you have imposed your will upon inanimate nature, and forced it to do your bidding. You feel the rush of power, the satisfaction of victory. You are the master!
That’s the good news.
The bad news is that you’ve made a mess of things along the way.
This is inevitable. It takes a great deal of focus and endurance to get a system working just right. While you are consumed by that focus, you have little room for niceties like small functions, nice names, decoupling, and cleanliness.
My apprentice and I just finished achieving a major milestone in FitNesse. It used to be that each new release of FitNesse was contained in a zip file that had all the files and directories laid out just perfectly. This is great for a brand new installation, but doesn’t work so well when you are upgrading. What we managed to get working last night was the ability for FitNesse to self-install from it’s jar file. Now, whether you are installing for the first time, or just upgrading, FitNesse will install itself into your environment appropriately.
If you’ve ever written a self-install like this, you know there are lots of niggling little details to attend to. While the problem is conceptually simple, the realization is a maze of complexity.
Last night, with dinner waiting on the table and getting cold, we got the last little problem licked, and saw the whole self-installation work as we wanted. We congratulated each other with a high-five, and then went upstairs to eat a well-deserved meal. Later that evening I went down to the office and checked in the code.
This morning I woke up, and while in the shower, I realized that we had a lot of work left to do. We need to go back over all that code and clean it up. I’m sure we left a swath of detritus while on the hunt.
The rush of victory should never be confused with the cold and crystalline concept of done. Once you get your systems to work, you still have to go back and clean up the wreckage left behind by the victorious battle. You are not done until the victorious code has been cleaned, polished, and oiled.
Comments
garem@sanssucre.ca 19 minutes later:
I agree! so it means don’t show management that it works until that step is done or you won’t get to do it.
Mike Bria 24 minutes later:
Indeed. A topic hot on my mind lately. Basically, there are a multitude of seemingly excellent reasons to get to gold while leaving behind some non-trivial level of debt. This is true regardless of your experience or skill, its situational, as you’re giving an example of.
I’m not sure yet in my own mind how okay this is or is not, but what I do know:
Having the discipline to go back and remove the battle carnage, though – this is what makes the difference between inevitable demise” and “continued success”.
Christian Hedin about 2 hours later:
I love the ingress to this article, I want to use it somewhere. :-)
Doug Bailey about 4 hours later:
I have an index card at my desk.
Make it work Make it right Make it perform
I think I got it from one of your talks. I still need the card, because it is really easy to forget about steps 2 and 3.
Monis Iqbal 1 day later:
100% agreed. ‘Done’ should be the final acknowledgment of the clean, optimized, working code.
abby, the hacker chick blog 2 days later:
Congrats on the progress with FitNesse and agree whole heartedly!
But how do we INCENTIVIZE developers to do this? When on most projects the unclean code gets them the recognition of “done” from their managers, what can we do to make it so that they really don’t believe it’s done until the code is clean?
Derek Smyth 3 days later:
Yes but I have noticed that the “get away from it for a while” is an important step to this.
The mind uses the ‘hacking’ to learn the process being developed and the ‘break’ to organise what was learned.
After the ‘break’ cleaning is easier as it’s been organised better by the mind.
tim Ottinger 3 days later:
Doug Baily: is yours like this one?http://agileinaflash.blogspot.com/2009/03/make-it-work-make-it-right-make-it-fast.html
Torbjörn Kalin 10 days later:
Is it really inevitable to neglect the refactor step in the TDD loop?
I would say it’s unproductive not to clean up your mess directly: it’s part of that oh-so-important feedback loop.
I blogged about it a few months ago.
nike shoes hosting 5 months later:
The mind uses the ‘hacking’ to learn the process being developed and the ‘break’ to organise what was learned.
Tim Ottinger 8 months later:
@abby the hacker chick:
I have learned from Esther Derby’s writings that the secret to motivation is to stop demotivating. If they weren’t rewarded for the wrong things, the right things would become more interesting and exciting.
just a thought.
Tim