Mr Andersson

Being an enthusiastic software developer is not without its battles. As an metaphor I would like to illustrate this particular (kind of) battle I think of, with some of my own experience as a parent and a bit of a cooking “enthusiast”.

Ok, so you come home late with the kids and you have just had a great time in the park playing around all afternoon. The kids are happy and you feel you have a nice quality moment in life. You also feel quite satisfied with your big dinner plans. Tic-tac-tic-tac. Time flies and you hurry to get home in time for..
Next stop: Dinner.
You: Really enthusiastic about good cooking, nutricious food etc.
Time: Just too late. There is no time to prepare a nice meal of food from the ground up with hungry kids running around, soon screaming and beaten up by each other..
Solution: What was the phone number to that near by pizza/burger/salad/indian/china restaurant again?

If you think of situations like this but with defect software in production, you might have taken one of the following paths what regards the “solution” part:

“- Hey, let’s solve this by increasing the disk space for now so that Windows Error Reporting doesn’t fill up the system volume with error logs”

“- Request timeout? Let’s add another web node so we can continue with our big deployment. Let’s investigate the timeout issue later.”

Depending on your current situation you may right now feel “yeah, what’s wrong with all that?” or “Stop procrastinate! I would ever never do such things – fix the real problem instead”.
Of course you want to start from the ground up and build quality in, but when the shit already have hit the fan, what would YOU do?
I’m not saying that eating fast food or cutting corners in systems development are good things to do all the time. However, there are differences of having a failing/defect system in production and when you are in “experimentation mode” (a.k.a building new features).

For both cases of experimenting/developing with cooking and doing software development, you don’t know for how long you need to experiment to get it “feature completed”. What you DO know is that you for sure want to “get it right”, but again, not necessarily “feature complete”. Therefore you have to do timeboxing to deliver on time without any loss in quality.

To avoid being in the park with the kids too long in the afternoon I can easily add some more automated tests. I can set up my mobile phone to buzz a sound. I could also check the azimuth of the sun, look at the clock tower, use a wrist watch and what not to get a signal when it is time to get started with the dinner.
But even though these tests are valuable and can reveal defects, they are no good if I just ignore to use them.
As I said before, it’s probably not a problem if this happens one or two times. But if you continue doing this you will have a quite dissatified customer (the family).

Or would you? Really?
It certainly depends on how you define what quality time with your family is about.
(yes, believe me when I say my own and my common-law spouse’s definition of “quality” DO differ when the shit already hit the fan in terms of cooking dinner in the weekdays )

The same goes for computer systems running in production. You and your team may have a higher tolerance (for what some people would call) defects in production.
Maybe you aren’t a “timebox” person and maybe you define quality in other means than the number of automated tests / automated test coverage percentage.

When development tools mature, people changes their minds and/or gets replaced, the definition of describing “good quality” of a particular system may also change alot during the lifetime of the system.
The challange is not just about more automated tests. It’s about developers and managers (a.k.a. people), LOCs, test coverage, tools, time and process.

Further reading:
* The engineering manager’s lament
* Choose Two – The Project Triangle
* We Need More Automated Tests