The rule says: 1 new technology goes into codebase only after 1 old technology goes out.
This is a simple empirical rule that we've coined with Joannes, while talking about business and managing technology. As it turns out, this rule makes a really nice guideline for planning future development.
The rule can apply to all sorts of things: new technological concepts, frameworks, ideas, tools and software. Basically, a technology in this list is anything that a new Junior Developer will have to learn about the project, before he can productively work the assignments.
This approach encourages technology pruning and explains how to structure technological evolution of your company, almost turning this process into a game. This is quite important, since otherwise it will be hard to "embrace the change" and leverage new technologies and tools, as opposed to being hit hard by every new "revolution". Essentially it helps to define your own Technology Radar at the project level.
For instance, we have the following evolution path for the User Interfaces in the world of Microsoft .NET Framework:
- Windows 8/HTML5/some Metro UI
If you treat these UI technologies as something to focus completely on, then every new change might be quite expensive (i.e. from Silverlight to HTML5), because of the way the problem is being structured:
We are going to develop new eCommerce suite with Silverlight.
However, treating technologies as something transient and replaceable can reduce costs and even improve architecture (making it more resilient to risks and changes). Consider this way to structure a problem:
We are going to deliver eCommerce suite, while using Silverlight for UI for the time being.
Obviously, this approach requires an architecture that favors decoupling and simplicity (i.e.: CQRS/DDD/ES methodology). However, this is not limited by the software architecture alone. Here are some samples:
- Version Control Systems
- Testing Approaches
- Project Management Concepts
- Integration Servers
- Deployment Strategies
- Serialization Formats
Another interesting side effect of this Golder Rule of Technology is that it encourages developers to simplify and refactor in order to be able to try some new cool things in the project.
And sometimes, when you get rid of an old technology, there already is so much improvement, that you don't even want to add anything instead. One example of such replacement in place is gradual migration from traditional SQL-driven persistence to Event Sourcing at our place. It allows us to discard quite a few items from the current stack:
- NHibernate with all the related binary dependencies
- SQL Servers along with the entire concept of relational database and object-relational impedance mismatch
- Evolutionary databases and managing them (including upgrade scripts and unit tests working against mock databases to verify behaviors on continuous integration servers)
Another practical sample would be - planned replacement of API implemented as REST via WCF (with SOAP and all sorts of weird configuration problems) towards a dead-simple implementation on HttpListener.
An interesting thing is that I never really considered complexity of technologies related to a feature till starting to think about that in terms of "Return on Technology Introduced". As it turns out:
- Usage of technologies is extremely overrated (sometimes attributed to the marketing hype related to certain buzz-words).
- Usage of additional technologies tends to increase both burden and complexity of a project at hand. Emprical evidence suggests that linear increases in these - lead to exponential rise in project costs.
The process of complexity increase can continue till the project becomes so expensive that it stalls. By reducing the number of non-essential technologies used, we can have better management of overall complexity (fighting delays, quality problems and costs).
In essence, simplicity is a technology of its own. But it does not count as one.