Are You Coding on Thin Ice?
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.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)