Should you work with old technologies?
2016-08-15 07:49:37 +0200
Why should a coder avoid old technologies?
Large complicated systems are often written in older technologies
Newer technologies can mean assignments with fewer lines of code and more greenfield development. Since the amount of code is proportional to the amount of time and people spent working on that code. Greenfield development is easier than working with millions of lines of code. It can however be an interesting challange to rewrite an older system.
In order to sell consulting services, many people will push for new tech.
Since the market value of a coder is related to experience with the current technologies in use, knowing and working with new technologies is a good policy to stay competitive. This means that even regular employees will push for new technologies.
Writing new libraries
Working in mature technologies can mean that the trailblazers have solved many of the problems. What's left is to try to get patches for potentially unmaintained libraries. If you are one of the trailblazers you can increase your market value by providing a library that many people use (thus people get to know your name). You will need to market the library in order to gain attract developers to write pull requests and contribute issues. Good way of marketing a library is to present it during meetups or conferences.
Why should a coder avoid untested technologies?
New code without tests or insufficient test coverage has a greater probability of bugs. As development of new things progress, the API's will change until they mature. The maintainers may wish to iron out quirks from the API's.
If the new technology is radically different from the old (angular vs jQuery), the amount of time spent learning impacts your ability to deliver. This cost can be sufficiently small if you know that you will have a lot of things to deliver (i.e. you know that you will spend enough time on the code). In order to avoid information overload you might want to have a mixture of known and unknown. Some developers are better at grokking new libraries and languages than others, but you still need to think about the team.
Trailblazer moving on to greener pastures
A trailblazer might want to move on to the next language after creating a few new library. Or if the technology becomes somewhat popular (without people that want to help out) the maintainer might not have enough time on their hands to support the library. This means that some libraries might become abandoned. Talk with the original author, sometimes they can be convinced to pass on the keys to NuGet, github et.c. as long as you are willing to help maintain the lib and review pull requests.