Monday, June 16, 2008

A vending Machine for Crows

Simply amazing in concept. He's trained captive crows to collect spare change. Now posits a device to train wild crow to do the same...and more! Forget the sharks with frickin laser beams! I scream for crow! [Beefheart] I've got an enourmous murder of crow here and am willing to bet that this wouldnt be taxable income! Joshua Klein, Mobile, Personal, and Future Technology Specialist

Wednesday, June 04, 2008

Iterative vs. waterfall software development: Why don't companies get it?

Sometimes it seems my entire career as a software professional has been framed in this long suffering debate about development methodologies. I think I subscribed to the big planning, big requirements, big design upfront concept for a few early years. Eventually I noticed the soul crushing death marches, huge overruns, and scandalous politics so common to PMI/waterfall projects and nearly went back to law school.

It was my good fortune to work on several dot com startups and the works of Booch, Rumbaugh on UP and later Ambler, Beck and Fowler on agile approaches that convinced me that there was indeed a more profitable and humane way to produce software.

It worked well when the focus was on innovation and entrepreneurial ventures. When there was a mix of people focused and actually engaged in delivering product, not satisfying prediction. Once the companies dragged in a few too many investors and the obligatory sr. management that things started to come off the rails and the focus became, to my mind, too much focused on prediction, rigorous estimation, and unrealistic expectations.

Again I find myself in an organization struggling with how to manage the software process. In this case we are playing from a technical deficit and have a service orientation rather than a product orientation. We try to say yes to everything and often over commit and under deliver. We have the typical mix of middle management that has, to my mind, spent dangerously little time involved in the craft of software development and tends to see software as a manufacturing problem, not a creative one.

This debate will heat up in the coming months and I'm not sure I have the strength to fight it again. Scott Ambler once told me "You either change your organization or you change your organization."

This post is both a place for me to dmup some links and fodder for the coming discussions and a plea to anyone who's listening to chime in on which end of Ambler's paradox I should take up.




[]


Iterative vs. waterfall software development: Why don't companies get it? [Computerworld]

[]


The problem with waterfall methodologies is that they don't work all that well. Trying to create complete, perfect system specifications before you start any coding simply ensures you've wasted a bunch of effort, because once developers start coding, design flaws become evident and require that you revisit earlier stages.

Except that you can't, because that stage is complete and there's no budget for going back.

This isn't something that can be fixed by getting better at design and specification, because the more you try to design everything before you start coding anything, the longer the delay between requirements and production. That delay means some of the design "flaws" aren't flaws at all - they're changes that are the result of the future not looking exactly like the past.
[Infoworld: What "waterfall" means ]

[]



Perhaps not authoritative but a good bullet list of when iterative makes sense and a (shorter) list of when waterfall makes sense: [http://www.joisinc.com]

[]



Good, if cheesy, flash video contrasting Agile vs. Waterfall: [A Tale Of Two Teams]




[]




Good metaphors for incremental vs. iterative and some witty agilist thoughts: [agileproductdesign]

[]


Fabulous origins of "The New Methodology" by Fowler. Plainly lays out the motivations for agile & iterative.

[]


Ambler's rants about agile planning. Explains the problem with WBS, GANTT, PMI and MS Project.

Explains the schedule by value vs. task here:
Agilists typically schedule the development of requirements (user stories, features, use cases, ...) into iterations as the line items, not tasks such as design, test, .... For example, the line items of iteration 5 might be "Implement Search for Books", "Implement Search for DVDs", "Implement Process Mastercard Payment", and "Implement Capture Different Billing and Shipping Addresses" for an online e-commerce system. These line items would stretch the length of the iteration, I would trust the team to schedule the actual work appropriately and wouldn't go into any more detail in the project schedule.

[]



In the end, laughter might be necessary: waterfall2006