A Checklist for Evaluating New Technology
gustavwengel.dk
gustavwengel.dk
1. How much work will it be to /completely/ replace old-tech with new-tech?
2. Does new-tech give us advantages that outweigh that switching cost?
My rule of thumb is that new-tech can't be an incremental improvement on old-tech - if it's going to have a decent ROI when it comes to switching cost (and re-skilling cost and so on) it needs to be a HUGE improvement - either a multiplier of developer productivity or enabling features that simply cannot be built with old-tech.
The worst result - which I've seen far too many times - is that new-tech only 50-80% replaces old-tech - and now you have to maintain both.
i’ve seen this too, (in apps) where there are 3 different “reactive” libraries in use that all do the same thing smh..
my feeling is, if you are going to change out the technology, then to avoid said problem of maintaining both, is the change needs to happen very very quickly to avoid having to maintain the old one while getting side-tracked to implementing new features and the transition gets sidelined... its very difficult to pull off
I have seen this problem too many times. Some team find a framework/language combination that makes their lives slightly easier in the short term and want to go for the new technology. But, they do not think about how we will scale that knowledge or what will happen if the code is moved to another team.
A couple of times I have been in the situation to have to re-write an application to the company common language (in one case Java, the other Javascript) because the receiving teams did not liked the technology and did not wanted to spend personal time learning something that was not valuable to them.
When a new framework is adopted, it is a commitment that we will train the developers and let them experiment, fail and learn until they take hold of the technology. It takes tame and the decision cannot be taken lightly.
My biggest problem though isn't which scripting language someone should use for some task. It's getting them to the idea that they should use a scripting language for some task.
People forget that HN is not the norm.
People like to do premature optimization, and choosing the language is one way.
People love to take that quote that was talking about a very specific thing and use it to justify not thinking about performance at all.
Because algorithm improvements can dramatically exceed execution time improvements, working in a language that facilitates rapid development and iteration is a path to better final performance than early optimization for execution speed, which is then difficult to modify.
That said, premature coding is also a negative - it pays to evaluate and refine the algorithm before coding - but sometimes executable pseudocode helps in that process.
Far too many programmers simply don't know ANY scripting languages. So the concept that they might want to write a quick script to do some task is simply not in scope AT ALL.
Anyway, I've seen people opening sockets in Prolog, and I've seen people doing artificial intelligence in C.
It's not about optimization, but it's surely possible to pick the wrong language for a task.
Nothing prevents anyone from writing their Java builds in, say, Python (shelling out to javac when needed) but no one does and with a good reason.
What's the reason?
It's quite astounding that architectures their size are implemented with the "slowest language around". It would be very interesting to read in-depth how they manage to sidestep the performance problems (that are brought up almost always when someone mentions Python).
2nd check is there a link on the website for developers.
3th Are they hiring?
This is an extremely naive take.
I’m curious about how many people actually approach technology evaluations with this mindset.
All the best technology decisions I have made have come with a strong friendly community.