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
