Technology changes quickly. Every week there are new tools, frameworks, and paradigms. Choosing the right technology for a new project in a constantly changing landscape can be daunting. Popular developer websites (and blogs!) are filled with articles on “the next big thing” which every developer “must” know.
In my experience, most of these technologies will be short lived. Some will prove useful over time, but most will not. Microsoft is well known for publishing a few new technologies every year. However, most of them don’t last. Remember Visual FoxPro or CardSpace? They were technologies which tried to solve a real problem but for some reason, didn’t survive in the wild. Today we have LightSwitch.
The open-source community also suffers from the same problem. However, it’s failures are far more numerous and less high-profile. When an open-source project fails, people just shrug and move on to another solution. I was a fan of Embperl until regressions prevented me from being able to upgrade.
The constant implementation of new technologies leads to technical minefields. A development organization which uses different tools, frameworks, and technologies will have major problems with staffing and support. Staffing becomes an issue because of the “key-man” problem. Only one person (the key-man) knows the particulars of a niche technology. Also, it’s harder for developers to be fungible, meaning they can’t easily switch from project to project. Support becomes a problem because we forget old technologies which we are out-of-favor. Finding developers to support old or obscure technologies is a major problem. Hiring managers can find themselves at the mercy of extortion-seeming hourly rates.
Failed technology leads to several problems:
- What about all those implementations of now-defunct technology?
- Who is going to support those?
- Should those be moved to something new?
My advice is this: Don’t do it! Avoid getting into this position in the first place. Projects get into this position because developers want to use the latest technology. There are many fun new things out there. However, most of them are not ready for production applications. Also, much of the time, there are few (or zero) developers who know the technology (especially within commuting distance of your office). I use a simple benchmark rule for adoption of a new technology:
The 1,500 Dice Limit : Don’t consider a technology unless there are over 1,500 jobs asking for it on Dice.com
Once a technology has passed that threshold, then the development organization can do a technology assessment to evaluate if it will fit your needs. Allow developers to experiment and prototype with the technology and prove it’s merits. Usually, this alone will fulfill the developers desire to learn something new.
However, allowing developers to lay technical minefields is a costly mistake and ultimately doesn’t serve the client or business. We value working software. Working software is supportable and extendable. As an organization, you are better served by picking mainstream technologies for your production applications.
Weekly limit reports are now available on the 1.5K Limits page.
- Everything is a P1 - July 22, 2020
- The Danger of Agenda-less Meetings - April 21, 2020
- Strictly Agile - February 12, 2018