See also a podcast episode where we discuss this topic.
Modern systems require the integration of technology, often from many sources. This can come in the form of processors, integrated circuits, operating systems, open-source software components, databases, messaging systems, cloud infrastructure, programming languages, build systems, frameworks, etc. All technology follows a trajectory — an example is shown below. The timeline may be short or long. Your usability threshold may be low or high, sloped right or left, etc. But the fact remains that most technology will eventually be replaced by something newer. We can debate whether or not newer is better, but the fact remains that time marches on.
Why can’t we use a particular technology forever? With hardware, components may not be available. With software, we potentially have a little more control, but if we want to use a software component beyond the above cycle, then we have to commit to taking over maintenance. This means:
- if there are bugs, we will fix them
- if there are security problems, we will fix them
- if there are build problems with new versions of compilers and other libs, we will fix them
For complex, networked projects, this can be a significant undertaking.
But a far bigger issue is that of value. Open source software and corresponding ecosystems are continually improved over their life and value is added. If you use projects in your development that are being improved, then value is being added to your product. The rate at which value is being added correlates to the slope of the curve above.
To extract the most value from technology, it is generally best to adopt technology when the trajectory is rising and there is project momentum, not when everyone else has moved on. There are several reasons for this:
- the rate at which value is being added is greatest during this period. This makes what we are building better.
- you have an opportunity to participate in and influence the development
- you have more time to benefit from the technology
- more support is available as there are more people participating in the project
- in programming languages, there are more maintained 3rd party packages available
We also need to select technologies that have a reasonably long life cycle as switching out a complex component can be a lot of work.
There are many other perspectives by which to evaluate technology — this is just one of them. Technology follows a trajectory from inception, growth, maturity, decline, and finally obsolescence. How do you know where a particular technology is on the curve? It is probably partly gut feeling, part experience, part asking others, and perhaps there are analytical ways to approach this as well (search engine ranking, etc). But the most important thing is to use this concept as a framework for objective thinking and evaluation. Effective technology selection is a long-term effort. We need to have a process. We may have to watch a project for a year or more to get a good feel for it. Most of us can’t significantly change the trajectory of most technologies, but we can choose where on the curve we will participate. Inefficiencies occur early and late on the curve. If we are always too early, we likely won’t get much done. If we are always too late, then our products will be a few steps behind everyone else’s.