| The pace of change in software-intensive systems continues to accelerate at a dizzying rate. This presents a huge challenge for people trying to develop useful software. In the early days of software development, developers could freeze the requirements for the software, develop the software to the requirements, and deliver the resulting software two years later with confidence that the requirements would still be relevant and the software would be useful. Most of our software engineering processes, methods, and tools were developed and used under the assumption of relatively stable requirements. Examples are formal specification languages, performance-optimized point-solution designs, fixed-requirements software-cost estimation, earned-value management systems, requirements traceability matrices, fixed-price/fixed-requirements contracts, and a general attitude that “requirements creep” was bad in that it destabilized software development.
However, as these practices became increasingly institutionalized, the accelerating rate of software change made them increasingly risky to use. Projects would use them for two years and become extremely frustrated when the users were not interested in the obsolete capabilities that resulted. Projects would fall behind schedule and use static models (time to complete = work remaining divided by work rate) to try to make up time by adding people, and run afoul of Brooks’s law (adding people to a late software project will make it later). Or they would sprint for the finish line using a point-solution design that satisfied the initial requirements but was extremely difficult to modify when trying to satisfy users’ changing requirements.
Ironically, even with all of these difficulties, organizations would increasingly turn to software and its ability to be electronically upgraded as their best way to adapt their products, services, and systems to the increasing pace of change in their business or operational environment. |
