Which scenario do you like better?
You wake up in the morning. The sun shines brightly through your window, but for all you care it might as well be pouring with rain. The bug reports are stacked high and low on your desk. The minute you walk in someone from support will be on your back about clients X, Y and Z who have effectively been unable to use your software for days now, making it impossible for them to serve their clients. You hope the coffee machine is working. Otherwise you will have to go down to the floor housing sales and product management. They will jump at the chance to ask you how features A, B and C are coming along. Features they have been waiting on for months now. Is Gary back from holiday today? Darn. That means that you will have to explain why it took so long to fix the export to Excel thingie you thought would only take half a day. Gary is talking about hiring more developers to regain some speed. Nice and all, but where are you going to find the time to train them? The prospect of all this weighs you down, draining all the energy you regained while asleep and then some. You drag yourself out of bed and to work. Not because you enjoy it, but because you need money on the table to pay your bills.
You wake up in the morning. The sun shines brightly through your window. You squint a little clearing the sleepiness from your head. Today is going to be a good day. You are going to finish that cool new feature client C requested two weeks ago. It was an interesting challenge. You learned a lot in the process. It isn’t the last. Plenty more features in the pipeline that will be fun to build. Justin, the product manager, will be around this afternoon to discuss a couple more ideas. Sales have a few prospects that are requesting special features and Gene, the support manager, would like some extra reporting so he can detect hot spots before they become a problem. Oh and Bill is coming over for lunch. Lunches with Bill are the best. Bouncing around ideas and coming up with better ways to do stuff always gets both of you going. Would be interesting to take the new hire along. See how he responds. The prospect of a good day gets you out of bed with eager anticipation.
I am absolutely partial to the second scenario.
Yesterday I ran across a post on software quality.
It struck a chord with me. It articulates exactly what I feel.
I care deeply about software quality. Not to alleviate my innate fear of failure. Not out of perfectionism. Not to do things “right”.
I care deeply about software quality because it keeps my work fun and interesting.
I’d much rather be building new features than fixing bugs. I prefer to work without the pressure of “fixing” things as fast as possible because a client is screaming hell and bloody murder.
Building quality software is the only way I know how to make this happen and to keep it happening.
All other ways of building software may seem to have very big advantages, but those advantages only manifest in the short term.
Like delivering results quickly.
I like delivering results quickly just as much as anybody else.
Even if you need to take shortcuts to do that.
Shortcuts are fine only as long as you redo them properly immediately after delivery of the feature. If you don’t, those shortcuts come back to haunt you.
Unless you address them immediately and ruthlessly, every shortcut, whether in code, in tests or in documentation, makes new features a teensy bit harder, less reliable and more work to implement.
Which slows down delivery of new features.
And which can introduce subtle bugs that you will have to fix at a later stage when you are no longer familiar with the subject.
Fixing bugs also slows down delivery of new features.
Taking one shortcut may not seem like a big deal. The effect is limited. But unless you fix it, that tiny bit of extra work needs to be done every time you deal with that code. It cumulates quickly.
You think you can take that hit. It is in some part of your code that doesn’t get changed often, so the effect remains limited. No biggie.
However, there is more to accepting a shortcut than accepting the hit on effort required for future changes.
It sets a standard.
That shortcuts are somehow ok.
The more shortcuts you take, the bigger the effect.
After some time of taking shortcuts, the speed at which new features are delivered really starts dropping.
Bug lists get longer. Implementing new features requires more and more knowledge that hasn’t been made explicit anywhere. New hires take a long time to get up to speed. Seniors are stretched beyond breaking point implementing new features only they have the experience with your code base to do properly and guiding less experienced colleagues.
Parts of your code will be in dire need of refactoring.
There will be parts of your code you don’t dare touch for fear of introducing bugs or inadvertently disabling features that you no longer even know exist but that your clients rely on.
The calls for a rewrite will start to be heard and grow in frequency and intensity.
The first scenario looms large overhead.
The only way I know how to avoid getting into that first scenario is relentless attention to and striving for quality software by everyone on the team. Just like Bob describes it in the last paragraph of his post