8 April 2010

Getting Dirty

Put simply, humans need to be dirty. We literally need to have bacteria on our skin in order to be healthy. All of the handwashing and sanitizer we foist upon our children is meant well, but in reality we're actually doing as much long-term harm as we are short-term good. The fact is that we as a species evolved in a dirty environment - we didn't have soap or hand sanitizer 50,000 years ago!

The same type of side effects occur when a software development team doesn't work in an environment where they're allowed to get dirty. They aren't allowed to experiment. They aren't allowed to fail in small ways that allow the team to learn as they move along. Everything has to be perfect the first time, or it's considered a complete failure.

So, how well does that approach work? What are the side effects of sanitizing the development environment to remove all dirt? Innovation is stifled. Code becomes riddled with Technical Debt because there is fear of making the changes required to keep it clean. Eventually, it costs an increasing amount of time and thus money to maintain and extend the code and ultimately a complete rewrite is required.

Wouldn't it be less expensive and much more effective to allow teams to play in the dirt and find ways to improve the software in smaller ways over time? Yes, there will be occasions where the small experiments won't work. Yes, there is a risk that some of the small changes will break other code. But, like the long term effect of allowing a child's immune system to be exposed to staph bacteria early in life, the rewards of keeping the code fresh and clean enough far outweigh these risks.

So, paradoxically, if people are empowered to get dirty, cleaner code will result.

3 April 2010

Responsibility... again

I have ranted about professionalism and personal responsibility in the software industry before. Recently I've been coaching teams that have run headlong into that brick wall known as Technical Debt, and in all of those cases the excuse was "we didn't have time to do it right".

Frankly, I'm tired of that excuse. Seriously. Uncle Bob Martin has talked about Just Saying No in that situation, and also in his seminal We Will Not Ship Shit article.

For all the complaining we do about airlines, the aviation industry in general does a very good job of instilling a sense of responsibility in pilots and aircrew, and the software industry could learn a lot from that. For every fatigued pilot issue, there are dozens of unreported "good" things that happen. Here is an example where 3 pilots and an air traffic controller all did the right thing - they ignored scheduling and cost pressures and did what was right for their passengers and overall safety:

The duty of the Pilot in Command, be it in an A380 or a two seat Cessna 150 is to maintain safe flight. That overrides all other considerations, even instructions from Air Traffic Control. In this situation, the pilots all chose to put safety first rather than taking a chance. It's quite likely that no one would have been hurt if the A380 continued its approach and landed. However, debris from the blown tire could have been ingested into an engine causing literally millions of dollars of damage.

The next time you're faced with "just getting it done", remember what those pilots did. Are you willing to take the risk that you will cause the equivalent of a blown engine? Or, does it make more sense to take your time, do it right, and all but eliminate that risk?

Considering the extent to which software directly affects our lives now, I want to make damned sure that developers opt for doing it right.