A first delivery of our current project is going into production very soon. The team has worked hard and is still working very hard to straighten out the last issues. As with every delivery, pressure always rises a tiny bit. This is were the men are separated from the boys.
We have all been in those situations. When your boss or the entire management team is breathing down your neck in order to put out that delivery. Pressure is something we have to deal with in our day-to-day lives. Everything goes fine until you discover some hiatus in your otherwise perfect code. This is were professional, disciplined developers really shine. The reaction of most developers in this scenario is to hack their way to glory so they can compile and put out the bits as soon as possible. At one (probably more) point in our careers, we’ve all said that popular sentence that makes me cringe:
‘You know what? We’ll provide a quick & dirty solution now and come back to the code during the next sprint’
Well, I’ve got a newsflash coming up: there will be no next sprint and when there will be a next sprint, you won’t have the time to refactor that particular piece of crap.
O well, then we will fix it the next time we have to change or extend that particular piece of code. Wrong again. There will be not next time. There is no tomorrow when it comes to writing clean code. If you don’t deliver quality today, then you won’t deliver anything at all tomorrow.
Writing a quick hack in otherwise good code introduces a broken window. The next developer that comes along and starts changing the code, notices the broken window and starts smashing some more. Before you know it, you’re once so perfectly developed code is now a big ball of mud. I don’t know about you, but if I would ever buy a new house then I certainly won’t start smashing in windows. Why do we do that to our code and think that its a good idea at the same time?
If you thought that writing clean code is hard, then keeping code clean is even harder and requires pure discipline of everyone on the team. We like to believe that putting a quick & dirty hack in the code delivers value, but instead we achieve the exact opposite. The only way we can deliver value, even when we are under pressure, is providing the most elegant and simple solution we can think of. Developers who prefer a quick & dirty solution instead of a good and clean solution simply refuse to think about the problem at hand. Refusing to think is probably the worst thing we can do to our customers.
These are just some thoughts and observations I had over the last couple of weeks. Pressure is something that helps me to focus and brings out some of my best thinking (taking into account my mental disabilities).
Till next time
Balance. The road to Hell is paved in best intentions. Clean Code is about re-factoring and leaving the code in a better state than it was when you started. But the simple fact of the matter is; clean, elegant code *does not* make money. Yes, bugs cost significant amounts of money, but elegant code no more guaranteed to be bug free than “messy” code is guaranteed to be buggy.
Factors in successful software, in most typical business cases, ranked in importance would be:
1. Usability – It does what it needs to do.
2. Cost – It’s reasonably priced and/or delivered on-time & on-budget.
3. Performance – It does it in a timely manner.
4. Intuitive – It does things in a manner that makes sense without instruction, and work-arounds are easy to spot.
5. Stability – It doesn’t crash or do something weird.
Stability or bugginess isn’t black & white. That’s assuming there are minor issues in the application and no more than a “rare” crash in areas that are not critical operations. Obviously if it crashes a lot or bugs interfere with it doing what it’s supposed to do, then Usability is out of the door.
Writing “clean code” shouldn’t be about building it up from day 1 as the “perfect” elegant solution. It’s about ensuring that *when* you need to make compromises, the objective of all developers is to recognize the risk of those compromises and re-factor them out at the earliest possible time. Agile development is about constant re-factoring to deal with changing requirements and staying flexible with changing priorities. It ain’t going to be perfect all of the time, but it sure as heck should be getting better most of the time.
It’s a similar argument I’ve had with developers that want to write the “perfect” framework for applications, ultimately flexible and can be used for the next 10 years. The funny thing is that most of those same developers give rather blank looks when I ask them if they’re remotely interested in working with 5 year old code. Perfection is the target, but if I can deliver saleable, usable product in 2 years making compromises, or 4 years making no compromises, I will chose 2 years when it’s my ass on the line. I expect nothing different from the companies I work for, though I do still push back. 🙂
Upon reading my response over again, I do have one correction. “Clean” code *can* make money… Just write a book about it. 🙂
Mr. Py’s response is thought-provoking, but he leaves out one important factor: Maintenance. Delivery cost is only a portion of the total cost of software. Clean code is intended to reduce the cost of v2.0 (and service pack 1).