Where's the dishcloth?

Bugs!!!! Love them or loathe them, realistic developers understand that bugs are part of our everyday life. We have technical bugs, environment bugs, business logic bugs, integration bugs, somebody elses bugs and god forbid, stomach bugs.

Now apart from the stomach bugs. Who is responsible for clearing up this mess?

There are numerous approaches depending on the product(s) you have developed, your organisational structure and your focus on bugs in general. I prefer the ‘zero tolerance’ approach to bugs, however, others are quiet happy to have a level of bugs in their code and apply risk and cost ROI calcualtions to determine whether the bug is recitfied, and if so, when. I feel there is a whole post on that subject alone and I’ll save that for a slow news day.

Moving back to the tactics around who should be responsible for clearing up this shoddy code. If you work as part of a small team of developers or lone wolf it is likely you have little choice other than to get the developer who wrote the code to fix it up (look in the mirror). You are unlikely to have development support teams who act as dedicated bug fixers or access to a stream of developers on the graduate recruitment programme that fix up the bugs as part of their development induction process. The later two are certainly perfectly valid approaches although a little old fashioned in my view, after all, who trains up new recruits in the process of only showing you how not to write good code.

Personally, I believe that the developer who created the code should be the developer who fixes the bug. Obviously this won’t happen if they have left or are away on annual leave or a significant amount of time has passed, but in general it would be good practice to follow this process through. There are many fine reasons for either approach and no doubt I will conclude with some views around this a wee bit later.

For now, I prefer to use the anology of those everlasting worksurface ‘tea rings’ when referring to bug clearing methodologies.

“Tea Rings!!!”.

Yes you heard me correctly. Consider the communial kitchen in your office. You probably visit this vicinity between 4 and 10 times per day to make that cup of espresso stimulus or the relaxing afternoon chai tea.

The process is quite simple. You will carefully choose the serving vessel and may even warm it through first. You will likely compliment your brew with milk or cream and sweeten to taste, unless of course you actually listen to the advice of your dental hygienist and drink water only. Whilst queueing patiently for the kettle to boil like the quintessential englishman you will definitely have pondered your preferred order for mixing these ingredients. Water or milk first probably being the most important choice and certainly the one that has polarised the tea drinking world for generations.

More often than not this process is repeated throughout the day and with the exception of having to raid the dishwasher for a preloved teaspoon it generally goes without a hitch time after time after time. Software development generally pans out this way too. Once a developer becomes productive and uses your best practices they will be able to make a good brew (code) with no mishaps (bugs).

After all the effort analysing, prototyping, designing, creating and ensuring adherrence to your quality control processes you are finally ready to move your code (brew) to production or systems testing. From time to time though there is that unsightly spilage around the base of the cup as you pick it up. These are those tea rings that are etched on every spare post-it note pad on your desk or the coat the surface of that old CDR you are using as your cup coaster, the same coaster that once contained the backups of your companies servers.

So who is the best person to clear up this mess. As the creator it should be a small matter of picking up the nearest dishcloth and wiping the worksurface clean. But wait. When you look at the mess you notice that there are other tea rings there, some sugar mounds and a spattering of breadcrumbs from that cheese toasty you could smell from the other side of the office earlier. At this stage do you clean this lot up as well.

You may elect to wipe clean your own mess only, expell a little more elbow grease and time and clean all of it or choose to ignore the tea ring as in the whole scheme of things, it is hardly noticable in amongst the remainder of the mess. For me there is only one satisfactory approach and that is to deal with the issue as soon as it arrives.

It only takes seconds to analyse the problem and take effective corrective action. If you choose to mop up all the mess then you must be aware of the dependencies of fixing up all the issues. What appears quite simple may take longer and if the mess is particularly ingrained you could actually damage the efforts of others.

Doing nothing though really isn’t an option either as this creates an environment that bugs are satisfactory. Housekeeping is just as important in the office kitchen as it is with keeping your code and products bug free. If you do favour seperate teams or graduate programmes for doing the teams dirty work, imagine for one moment how they feel knowing that they are merely cleaning up other peoples mess.

Lastly, how are your developers ever going to get better and improve your product if there are no consequences for producing shoddy code in the first instance.

Thanks for reading.
Lee.