In the most basic of all development methods, generally categorized as the waterfall method, each stage, from application concept and budget estimation through requirements, specifications, coding, and testing are handed off from one organizational subgroup to the next. Thus coders code, testers test, and business analysts analyze -or, at least, draw diagrams, and every new signoff speeds the project to its inevitable end - a raging success when encountered on resumes and usually just another source of user frustration in reality.
What's most fundamentally wrong with this process is that it evolved to fit tools, agendas, and reporting relationships last seen in the 1950s and is roughly as out of place today as a mid fifies jeepette in Afghanistan - something, by the way, successive Liberal governments have forced Canadian troops now there to use every day.
The canonical substitute is the object oriented development process - which cheerfully retains the same organizational structure but breaks the project into smaller pieces ultimately intended to be brought back together through the miracle of messaging: aka consequential overhead.
We need to ask, however, what happens when we break the project into the smallest possible pieces? not so much bricks that can be brought together later to make a structure, but the bits of straw and clay out of which the bricks are to be made?
Imagine doing this without changing the traditional role separation and what you would get is a situation in which:
That's the reductio ad absurdum, but if you actually tried this you'd soon find ways to expedite matters. In particular you'd take advantage of the fact that the bits of clay or straw being passed down the waterfall here fall naturally into one of four basic groups:
In other words, if you had these standard bits ready to go, all you'd have to do is assemble them and then code the missing bits of group specific logic. But how? How do you bypass the steering committee, the waterfall process, the sign-offs waits, and all the rest of the impedimentia that make this so impractical?
Easy: sit down with some users, a decent workstation, and a 4GL development suite to do all of this stuff in a continuous loop:
It's called active prototyping -and it frustrates every rule learnt so painfully by the card punch people in the 1920s and 30s, but it applies to our time, our tools, and our needs. The bottom line? active prototyping works. It handles complexity, it bypasses all the opportunities for communication error implicit in the waterfall process, and it replaces "object oriented development" (i.e. organizational continuation through messaging overhead) with effective object reuse and linkage.
So how buggy are the prototypes? Lets talk tomorrow.