Agile Zone is brought to you in partnership with:

James is a consultant, author, and speaker. He brings a rare combination of business savvy, deep technical understanding, and an engaging presentation style to his work, putting him in demand around the world. James is a prominent figure in the Agile community: he is an inaugural recipient of the prestigious Gordon Pask Award for Contributions to Agile Practice and one of the first ten people to sign the newly-released Agile Manifesto in 2001. James keeps a blog at jamesshore.com and is co-author of The Art of Agile Development. James is a DZone MVB and is not an employee of DZone and has posted 60 posts at DZone. View Full User Profile

Are You Coding on Thin Ice?

12.22.2010
| 1575 views |
  • submit to reddit
Winter has arrived here in the US. Even here in the normally temperate North Carolina, it's been 5 to 10 degrees below freezing for the last several weeks. A number of local lakes are frozen... or are they?

When you look at a lake with ice on top, it's a lot like looking at a software project that's "doing fine." It's very difficult to tell how thick the ice is. Will it support you? Is it paper thin or six inches thick? Can you walk on it? Or drive a truck on it?

There are a few different ways to understand the ice. You can look at historical data (it's been well below freezing for the last month), run a few experiments ("Joe, you go first!"), or ask a few people who live beside the lake ("It's never safe this time of year.") Or you could just be stupid and drive your truck onto the ice.

Software is very similar. Are you taking a naive approach? "Look! Everything's working. Keep moving forward." Sure, you're not automating builds. Your automated testing coverage is minimal. Most of the essential bits of knowledge around your system are in one or two people's heads. But it looks like everything is working fine. The water "looks" frozen. Why can't I drive a truck on it?

The problem with software, like ice, is that things can look pretty safe from shore, but still be very dangerous. Putting any weight on a thin project can bring everything crashing down very quickly.

Take some time this week and look at your project. Are there key factors you know your missing? Are there good practices you know you should be introducing, but you've been too busy? Frequent code checkins. Peer code reviews. Defect driven testing. Test driven design. Time boxed iterations.

Nothing? Okay, but watch your back... that water can be very cold, and it's usually deeper than it looks.
References
Published at DZone with permission of James Shore, 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.)

Tags: