Are You Coding on Thin Ice?
Join the DZone community and get the full member experience.Join For Free
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.
Published at DZone with permission of James Shore, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.