Your Code is NOT Somebody Else’s Problem

No matter how small and insignificant you might be, you can still be a catalyst of powerful change. An idea may give somebody the “Aha!” moment which, in a heartbeat, literally changes their entire outlook on life. They impart this change upon others and the process reverberates outwards – babbling brooks forming streams.
Telling a developer about the importance of automated testing is a mandatory, minimum requirement of being a software development manager. Kinda like grade school. You learn how to read, write and do basic arithmetic. Maybe you can even remember a favorite teacher, but the rest is a blank.
Showing a developer the ease of automated testing might get a spark started – TDD can become infectious if done right. You’re implementing learned knowledge (and, more importantly, how to cut corners and save precious time for other activities). And, this, unfortunately, is about the highest level most folks ever reach. They survived the manager from hell that forced them to write tests and improve code coverage without really understanding the underlying principles.
You must convince developers that code quality is their responsibility. Such an idea is on par with a university course covering human ethics and engineering. This is the tiny rock particle I mentioned at the beginning. And getting it moved will be one of many causes of positive and lasting change.
Just like telling a three year old “No!” for the first time, resistance will be swift and firm. Most developers burst out in a tantrum of foot stomping and howling. They don’t have the time much less the training to write tests. It’s not their job. Remain firm and show the benefits of moving quality control upstream. Toddlers know, deep in their hearts, the difference between right and wrong. Once you convince them they have the time, developers will too.
Next up on the list – telling system administrators about the importance of version control!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)






Comments
Mike Dzone replied on Thu, 2011/09/01 - 9:02am
Mladen Girazovski replied on Fri, 2011/09/02 - 5:24am
in response to:
Mike Dzone
Sure, if you do it agile, or better extreme (as in eXtreme Programming), than your code isn't finished unless it is tested, and you cannot check it in to SCM.
Thats what this article is about IMHO, you cannot simply state "it works on my machine for me" and commit the change, you need to write a test for it, that proves that some aspects of it behave as intended.
I often find that people confuse agile project management processes like SCRUM with agile development practices like XP for instance (CI, autm. Build, selt testing builds, pair programming, codce reviews, TDD, etc.), of course they work good together, but SCRUM by itself will not help the developer writing good code, XP will.
Jess Holle replied on Fri, 2011/09/02 - 6:32am
Any process where the problem is not first and foremost owned by whoever made the code addition/change has an issue -- it provides insufficient deterrant to sloppiness on the part of those doing code changes.
Sure, team dynamics may provide this deterrant instead -- but don't bet on it. The team may even extend this notion of group ownership and decide that the issue is somebody-else's-problem within the organization, e.g. they may decide the integration team should step in when their loused up code fails in an integration build.
Personal accountability is key in any case. Lose that and you're lost.