True Phases of the Software Development Lifecycle

David Harris — Thu, 30 Nov 2006 15:29:00 -0500

I’ve not been a developer for a long time, but I’ve been around just long enough already to learn the lifecycle of a “real world” project. Note that this is for single-developer projects. Team projects give you a lot more latitude and ability to make these things work more seamlessly. Sometimes.

Phase 1: Planning

Most projects at least, thankfully, begin with planning. It’s almost never enough, and rarely covers all the special cases you’ll later be coding late nights to fix. But there is still almost always a phase where you at least are given a set of features, maybe a basic UI desire, and a pat on the back. As the developer, you get hard to work designing the perfect database structure, thinking of clever ways to organize code, until a day or two later in…

Phase 2: “Git ‘r Done!”

This is the point where you have things about half organized in your brain, and then get told “We needed that yesterday!” And, the corollary, “Get it done, it doesn’t have to be perfect!” And it’s not perfect, not the shining gem you hoped to produce, but it works. It works for every case they gave you, and when you’re finished you sit back, hoping that’s all they want. But it never is…

Phase 3: “But see, there’s one exception…”

In this phase, you realize what they told you in phase 1, and which you used to shortcut code in phase 2, did not line up with reality. For example, they say “All employees come in at 8am and leave at 5am.” So when you’re rushing for release, you make that an assumption. Phase 3 is where they come in and say “Well, we have this one employee, Bill, who comes in at 10am and leaves at 3pm”. For a minute, you think you might can get away with coding that one special case in. Until you realize that later they’ll have yet another exception to cover. So you rewrite most of the business logic and make a few database schema changes. And in the end, you wind up with better code anyway, and start to feel good about what you’ve produced. Until the inevitable…

Phase 4: “I’m a creep, I’m a weirdo. What the hell am I doing here?”

Of course, we’re talking about the inevitable and dreaded Feature Creep. For months, maybe years, you add feature after requested feature to that nice little software package. Maybe it began as a simple timesheet application, but now it’s a fully functional document repository with full search and indexing capabilities. We’ve all been there. Thankfully, the end seems to be in sight when…

Phase 5: “We had to let Bill go…”

They make a policy change that renders that previous Phase 3 exception void. Maybe all employees are forced to get there at 8am. Maybe they fire the guy who keeps coming in late. Either way, they no longer need your clever system for time configuration, as it adds a slight bit of complexity they get no benefit from. Only now, the whole system hinges ever so slightly on that one bit of business logic, you know that if you even touch that code the whole mountain will topple. So you finally stand up for yourself and say “no!” And then you quickly come back with “Well, it would be possible if we did a…”

Phase 6: Rewrite.

Inevitably, your code will reach a point where you just need to rewrite it from the ground up. If you had known they wanted a document repository from the beginning, you would have designed it in. This phase gives you the chance to really plan things out knowing everything that should be included. So you work and work and release a final version that does everything right, only to find out that…

They hired Bill’s son, who works Bill’s old schedule.

And the cycle thus repeats itself.