Rubenerd

If you haven't read my relative James Ross's creatively titled blog Blood, Sweat and Tiers yet, then you haven't read my relative James Ross's creatively titled blog Blood, Sweat and Tiers yet!

His latest post concerns Agile versus Waterfall software development.

Long time no blog. I’ve been distracted in recent months learning about non-geek stuff like investing in the stock market, which I may blog about at some point. But what has inspired me to pick up my virtual pen again is the apparent mainstream rise in popularity of agile development. Bear in mind that I’m in Australia so your time lines may vary, but these days there are very large organisations stating agile development as a key aspiration and sending head hunters around about scrounging for anyone who can spell it correctly to lead them to the promised land. Five years ago we relatively early adopters of eXtreme Programming would band together and tell each other stories of what a wonderful world it would be when major banks and telcos saw the light and changed their evil waterfall ways. Now it seems we may have gotten what we wished for and perhaps we should have been more careful.

As soon as I heard the dreaded "W" word (no I'm not referring to George Bush Jr!) I had to respond!

G’day James!

From my limited experience in software development I can’t say I’m much of a fan of the waterfall approach.

Throughout Software Design and Dev class in high school and even at university now the teachers and textbooks drum into our heads that waterfall and structured development is the only way to develop software appropriately and that other methodologies such as my beloved RAD or agile time-release development are simply too unreliable for anything other than small projects. They claim less structured approaches are child’s play and that nobody in the real world with a decently sized cranium would consider using them.

The problem I see with the waterfall approach is that there’s simply too much overhead and fluff which gives the illusion that work is being done despite the fact nothing constructive has been achieved. While I agree that going headfirst into a project is foolhardy, I don’t think sitting in a boardroom in suits presenting pretty graphs in Keynote and PowerPoint for months really actually serves a practical purpose other than to make the boss happy; which may or may not be fulfilling your objective! A feasibility study should be produced, a rough schedule hammered out and work should start. Doing what needs to be done versus doing what you want to get done I think can be two very different things.

I’d consider using the Sashimi Waterfall approach I learned about last month, but only because I think its more flexible and sounds like Japanese food of which I am quite partial to.

Microsoft supposedly uses the strictest form of the waterfall approach, and look at Windows Vista! Perhaps when I join the workforce and the weight of the world sets in I’ll change, but for now I’ll just bask in my inexperience and continue to look critically at rigid, structured software development.

Love reading the blog!

Cheers,
Ruben

james ross, rad, rapid application development, agile development, waterfall development, redhill consulting, australia, programming, project management