 |
System Extensibility
Yes, I am on that soapbox. Ensuring that maintainability and adaptability are part of a system is a "best practice," extensibility is not. To the extent that a highly structured system is extensible, that is the end of any commitment to building for the future.
Adding hooks and stubs for something that may not happen, confuses and clutters the design of the resulting system. Building and running prototypes wastes time. Making a system extensible adds significant undefined scope. The reason is that no one knows what the future will bring. Furthermore, how can it be tested if the systems it is interfacing with are not defined?
This is one of the better philosophical underpinnings of the Agile methodology. Do not build for the future. Jim Highsmith said it well in his book Agile Project Management, "Simple design means valuing adapting over anticipating. This means designing for what we know today and then responding to what we learn in the future." Build a clean structured product and refactor components to account for current changes, however, leave the future for that, the future.
Leaving room in a hardware design for extension (i.e. ensuring the interfaces have expansion room) or ensuring software has the capability to adjust to areas known to be volatile, is perfectly sensible. Consideration for some yet-to-be-defined standard is over complicating and adding time to the design, additionally building and testing something that may need to be completely thrown away and rebuilt.
Too many engineers want to make their system fit the future by anticipating where and how the system may be used in the future. This is often hidden in what is simply referred to as "implementation details". The project's management and even the customer are left out of the decision. However, this is a huge area for internally induced scope creep, additional risk and increased cost. This is a recipe for project failure.
 |
Anticipation should be for areas of known change. Even this should be clearing called out so that the project team and the customer understand the work involved in its design and implementation. If they choose spent their time and money in others areas, that is their choice. The Project Manager will need to work with the technical team and their functional managers to instill this philosophy.
Tags: 
IT Failure Project Management Leadership
 |
 |
