DevOps Zone is brought to you in partnership with:

Having worked as both a developer and an operations manager, I’ve gotten all too familiar with the ever widening gap between what developers and customers consider “done”. In order to help narrow this, I’d like to share some of my ideas and experiences concerning the software development processes with a vision towards actually releasing what customers need. Daniel is a DZone MVB and is not an employee of DZone and has posted 27 posts at DZone. You can read more from them at their website. View Full User Profile

Your Code is NOT Somebody Else’s Problem

09.01.2011
| 8429 views |
  • submit to reddit
Imagine an ant working at the top of a mountain. Next to it, there’s a sluice of melt water running and, at that moment, the ant removes a tiny particle from the rock face. A few hundred molecules of water quickly seize upon the shortcut, and gravity takes care of the rest. The individual rivulets on the mountain’s face eventually run together in a small brook, jostling pebbles and twigs along its bubbly trough. Running ever downwards, doubling in speed and force, the stream now catches up rocks, branches and other streams join the flow. Almost effortlessly, a mighty river is born carving its way through the massive granite over millennia. The imprint upon the surrounding landscape is a culmination of billions of tiny actions – wind, rain fall, freezes and even one tiny ant.

Creative Commons License rmlowe

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!

References
Published at DZone with permission of Daniel Ackerson, author and DZone MVB. (source)

(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

Actually, doing things the "agile" way, my code really isn't my problem it's the group's problem since a mantra of agile is everyone owns the code right? All these rules...it gets confusing!

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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.