I started writing my About page, but what I wrote started to feel like an article more than a short summary, so here is the full text:
What is “Extensible”?
Extensible is defined in Wikipedia as:
In software engineering, extensibility (sometimes confused with forward compatibility) is a system design principle where the implementation takes into consideration future growth. It is a systemic measure of the ability to extend a system and the level of effort required to implement the extension. Extensions can be through the addition of new functionality or through modification of existing functionality. The central theme is to provide for change while minimizing impact to existing system functions.
Although forward compatibility and extensibility are similar, they are not the same. A forward compatible system can accept data from a future version of itself and pick out the “known” part of the data. An example is a text-only word processor ignoring picture data from a future version. An extensible system is one that can be upgraded to fully handle the new data in the newer input format. An example is the above mentioned word processor that can be upgraded to handle picture data.
In systems architecture, extensibility means the system is designed to include hooks and mechanisms for expanding/enhancing the system with new capabilities without having to make major changes to the system infrastructure. A good architecture provides the design principles to ensure this—a roadmap for that portion of the road yet to be built. Note that this usually means that capabilities and mechanisms must be built into the final delivery which will not be used in that delivery and, indeed, may never be used. These excess capabilities are not frills, but are necessary for maintainability and for avoiding early obsolescence.
Extensibility can also mean that a software system’s behavior is modifiable at runtime, without recompiling or changing the original source code. For example, a software system may have a public Application Programming Interface that allows its behavior to be extended or modified by people who don’t have access to the original source code.
Although usually applied to engineered systems involving software, it can be applied to any type of engineering. Houses can be built with future extensions in mind. The Prince Edward Viaduct located in Toronto, Ontario, Canada was built to accommodate a future subway line.
Though the application to software is relatively new, the word has been a rare but valid part of English for a long time. The Oxford English Dictionary cites examples going back to the 17th century.
For me extensibility means, thinking ahead without planning the future. In the classic waterfall model, this would mean analysing all possible future feature enhancements and adapting the architecture to be extendable. This method always misses the target though and causes more problems and frustration along the road. My philosophy is that using development principles like Agile, Scrum, RUP etc. will not make the actual software extensible, but it will make the code much more flexible. Agile is used to be able to quickly adapt to changing needs (required feature priority, etc.) during development, but one thing that’s normally not mentioned is the timeframe.
If the development process is based around being agile, adapting to change and delivering production quality parts, does it matter if these changes come tomorrow, next week or next year? Of course not. The biggest issue with creating software that is future-proof is often not the actual architecture, but the code and the organisation around it. If code is well documented and the project around it is fine-tuned for quick change, then the code will become easier to maintain and adapt, thus becoming extensible. Often when we’re asked to make changes in (older) system the biggest problem is understanding the architecture and code in order to be able to make the changes. I’ve often heard of and seen systems that were extremely hard to maintain, so badly even that noone was allowed to touch the code and a complete new product was being developed instead. If those nightmare systems had been made using Agile/Scrum/RUP, then this probably would not have been the case. I say “probably” since there are people out there that implement Agile just for the sake of it without truly understanding it, this delivering even worse maintainable products.
What it comes down to is this: It’s not the code that makes a product extensible, it’s the process that creates it that does.
