So this third article in the series of long overdue, but here it is: as promised in part 1 and part 2, part 3 reviews different software development methodologies.
How can there be different methodologies? Oh, I must mean like using Make instead of Ant, or using the Sun C compiler instead of gcc, right?
Not at all.
In college, your methodology is pretty much you get an assignment, head down to the lab and start hacking out code until it compiles and meets the assignment’s criteria. That works fine in 1-2 week projects that never need to be extended, reused, or maintained. And where the requirements are well-defined up front and the customer (ie. your professor) is just one person who also happens to be a software person and can communicate in software terminology.
But what about if you have a year-long project, with many different customers who sometimes disagree with each other and wouldn’t know a compiler from a salami sandwich? And what if they want to know on day one, with 100% certainty, how long it will take you to implement the requirements that they haven’t even come up with yet and will probably change anyway?
That is the reality of a professional software project.
Over the years, our profession has organized itself into a few general methodologies for how best to handle these realities:
1) Seat of your pants (ie. none)
This is much more common than most of us will admit. Really, really talented managers and developers can get away with not using any methodology, especially in a small, close-knit company. But lack of methodology quickly leads to disaster when:
–you’re in a large company, or
–you have a history of lack of trust, or actual failure, with your users, or
–your development team is any bigger than, say, two people, or
–even a single person on the project (including the users) is anything less than a world-class, hyper-talented individual.
2) Heavyweight (aka. Big Design Up Front)
For decades, our profession countered the obvious failings of projects with no methodology by throwing lots and lots of, well, methodology at the problem. The overriding assumption with heavyweight methodologies is that change is expensive and gets exponentially more expensive as the project progresses. If you make that assumption, it’s then logical to want to get everything right and laid out at the very beginning of the project in things like requirements documents, functional specifications and technical specifications. In this kind of project, you could easily end up with thousand-page documents describing your system in such minute detail that, in theory, a fifth-grader could implement it.
When most people think of heavyweight processes, they think of the Waterfall process.
As with many philosophies that are great in theory, heavyweight processes tend to fall over when applied to reality. Specifically, these realities:
–Users rarely actually know what they want until they’ve seen something tangible. Then they still don’t know what they want, but they do know exactly what they don’t like in the system you just delivered to them.
–The business environment changes rapidly. What’s valuable to a business at the beginning of a two-year software project could be totally irrelevant at the end of that same two-year project.
–Nearly everyone is really, really bad at estimating work involved in a writing software. And we all get worse (exponentially) the longer the time period we’re trying to estimate over.
For the longest time, we as a profession tended to blame the problems that pop up as a result of these realities on stupid users, or incomplete requirements. We’d find any little deviation from our incredibly cumbersome process and point to it as the reason our software project failed instead of realizing that it was the process itself making the project fail. Finally some smart people started realizing the process was broken and they gave birth to….
3) Lightweight (aka. barely sufficient)
Most lightweight processes in vogue today fall under the Agile banner. But the basic idea is to keep the big picture in mind at all times while delivering a software project: the purpose of business and commercial software is to create value in an organization somewhere for as little cost as feasible. That’s it. And the easiest way to achieve that is to have the people who need the software working as closely as possible with the people who write the software.
No approach is perfect, though. The biggest problem I’ve seen so far on Agile projects is facing this reality:
–The business (especially high-level managers) still want to know with 100% accuracy on day one when the project will be done, even if they don’t yet know what they want.
