Should software be designed for flexibility to meet future needs or should the software be designed as simply as can be, to meet current needs and requirements? I would argue the latter, which probably puts me in the camps of Fowler et al.
Here's why: if future needs are uncertain, trying to design for future flexibility may well build the software into a cage rather than yielding the desired flexibility. Sure, the software is "flexible" if the future needs match the predicted future needs built into the design.
On the other hand, if the software is kept simple, meeting the known requirements and designed well (following OO principles and such), when new needs surface, the software can be amended to meet those needs. Since there's been no predetermined design for this new need, this should provide the maximum flexibility.
This embodies the spirit of iterative, incremental development. Done right, IID should be agile by nature, not by following some certain prescribed agile methodology such as SCRUM or XP. I think many projects quickly grasp iterative development, but incremental development seems a more difficult concept to understand.
Understand this - if the goal is to predict future needs, with incomplete current understanding, then even if its called "designing for flexibility" - it really is little more than waterfall development. Incremental development isn't just about building the system in stages or phases. It is also about determining the needs, the design, the implementation, and the testing methodology in iterations. Of course, this means the project starts with an incomplete understanding of the details of the final system. That's no fault of IID - that's just the reality of things.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment