He goes on to say that developing software is not simply creating products - it's more about creating flexible solutions and supporting dynamic features that incorporate the "ilities" (configurability, durability, maintainability, portability). The core consideration here is the fact that software is all about dynamics - the development process, the final product, as well as the cost of construction versus changes. Structural engineering practices are built on paradigms that optimize elements related to the concreteness of the goals, often "cast in stone." Software practices are a different matter, and pushing for adopting structural engineering methods for software engineering limits the possibilities. In software engineering, the costs of modification are far less than the actual construction. Consequently, we should adopt a development process that leverages this unique capability.
"Software engineering dares more (than Structural Engineering) in some sense. We are asked to provide features not found in current civil projects. If we were to build a bridge as we build a software product, we should be able to provide all of the following - without an impact on the performance of the bridge:
Reusability: moving the bridge
Extensibility: extending its length (at runtime)
Scalability: adding a new level (hot pluggable)
The ability to replace the technology: from a concrete-based structure to steel (24/7)
Incremental development: first the pedestrians, then cars, then buses, then trains
Perhaps the architects of our homes and office spaces can learn something from software engineering in incorporating the 'ilities'?
No comments:
Post a Comment