لطفا منتظر باشید ...
Software
Another intrinsic benefit of making changes in small steps is that it helps keep software malleablesomething people tend to like because they think software should be soft. It should be easy to change. Making enhancements or fixing bugs in small pieces helps keep the system very granular. This improves the softness of the system and makes it easier to recover from mistakes, add more features, and test existing functionality.
Note that I'm not suggesting that software actually is or should be softthat it's easy to change. Changing complex software is every bit as difficult as changing complex hardware. It's just that the difficulty manifests itself in different ways. As Steve McConnell says in his book After the Gold Rush, "the insidious notion that it's easy to modify the behavior of complex software defies logic."[3] Any complicated creationbe it hardware, software, a complex mathematical formula, or some other sophisticated constructionis inherently difficult to modify significantly because it was likely difficult to build in the first place.
[3] McConnell, Steve. After the Gold Rush. Redmond, WA: Microsoft Press, 1999. Page 19.
Certain types of software changes are tougher and more pernicious than others. For example, requirements changes late in the development cycle are among the most damaging to a software project. In fact, substantial requirements changes late in a project can destabilize the project to such an extent that it can't be finished at all.[4]
[4] Ibid.
A common response to complaints about late requirements changes is that developers should build software as flexibly as possible in order to anticipate future changes. This is easier said than done. Flexible software comes at a price. It takes more time to build than less flexible software. Flexibility is nearly infinitely variable. Saying a piece of software should be flexible could literally mean just about anything. Flexible to what extent? So that it can run on multiple operating systems or different computers, handle alternate currencies, or use a dissimilar user interface metaphor? How far is too far? When does flexibility become wasted effort? And when is software so intransigent that it is no longer, by definition, soft? The only answer here is experience. The perceptive craftsman learns through experience how to design the software he builds with the right amount of flexibilityno more and no less.
