"The difference between theory and practice is smaller in theory than in practice" - Unknown
When I was in school, learning software development, there was only one accepted methodology in the industry - what is now called the Waterfall model, ironically proposed as a flawed approach. Despite that, even the iterative variation of the Waterfall model was influential in supporting the rigid separation of the phases of development - Requirements was to be finished before Design started; all Design was done before Development was started, etc. As the referenced Wikipedia article notes, many forces work against such a system being successful.
The first and foremost of these is that, except in government contracts, requirements gathering is never finished until the product goes obsolete. Few customers have a complete idea of what they want at the start of a project, especially one that is a new product for them. The initial idea they will have will typically be a computerized version of their existing workflow. As the storyboards are presented, they will usually OK them without much thought, spending most of the time debating niceties of field placement, drop shadows, and background colors. The Requirements Document is blessed by both sides, and Design begins. Once the Design Document is produced, reviews will start.
Document reviews can be a Hell all their own, but in most cases the customer does not have the expertise to critique a design in detail. Once they see the storyboard for workflow, however, they start to feel comfortable to assert themselves. They have some new ideas, or perhaps their workflow has changed in the meantime; sometimes government regulations have changed, or a new technology has emerged to catch the fancy of the VP. [I once lost a job when the Director in charge of my project was distracted by the new Apple Newton, and withdrew his attention from the politics of my project. But more about that another time.]
So new requirements roll in from the customer, after the Design is supposed to be done. But by now, the schedule clock is ticking, and so some development needs to be started, or the project will be late. So the team starts development, and the analysts respin the Requirements Document, and the designers respin the Design Document, and another review ensues. With luck, the new design does not seriously impact the work already done, but sometimes it will invalidate much of it, requiring a fresh start by the developers, and wasting more time.
And this brings us to the second big problem with Waterfall, as commonly seen in the wild: the Schedule never gets longer, even if one of the phases gets redone. I'll cover this in the next entry....
Technorati Tags --
Software
SoftwareDevelopment
Computers
Programming
No comments:
Post a Comment