Tag Archives: HowNotTo deal with bugs

Testing my patience or “Why do we make this so hard for ourselves?”

Anyone following my intermittent rants on rubbish code would surely have got the sense that I don’t tend to suffer fools too gladly. It is also no secret that I don’t believe in commoditising the act of writing code.  The results are always poor and always expensive.

Here, I fear, is yet another example of why I feel this way.

Recently I was wondering aloud with an offshore colleague how it can be that a simple bug which we budgeted half a day to fix was taking 3 days and as almost many attempts to rectify. Paraphrasing for you:

Me: Show me your unit tests

Them: Um.

Me: You DO have unit tests, right?

Them: Um. Well. Yes but they have been disabled.

Me: … Really?  Please tell me why.

Them : Not sure.

Me: Let me see if I have got this right. You have attempted to fix a simple bug and its taken you two failed attempts over three days and you STILL don’t have  unit tests?

Them: …. [silence} … [a sort of gargling sound, which I put down to a noise representing an uncomfortable mental state] … Um.

Me: [swearing internally] OK. Show me your code.

Therein ensued a 45 minute discussion which I shall summarise for you the dear and busy reader:

  1. Colleague did not know why the existing unit tests were disabled
  2.  Colleague discovered why. They didn’t work.  Better out of sight and out of mind, eh?
  3.  I (strongly) suggest that the key methods be broken up into smaller test-able methods.  This was done
  4.  New unit tests were written
  5.  Unit tests were then rewritten as esteemed Colleague had not understood the concept of determinism i.e. you put values into the test with the expectation that they will produce a predictable result
  6. Unit tests now passed
  7. Third bugfix attempt was deployed to test
  8. Third bugfix attempt was passed by the tester
  9.  For completion, the colleague was then advised to write unit integration tests.  This was initially deemed “impossible” due to a dependency on external services, to which I issued a sharp “rubbish!” in reply
  10.  Mocking of the services and creation of the unit integration test then went ahead smoothly, once I pointed out that it is indeed possible to have more than one constructor per class (sic)
  11.  Unit integration tests well under way
  12.  *sigh*

I am going to take up drinking hard stuff on a regular basis to thin my blood if I see more of this sort of behaviour

My heart can’t take it.