If a technology is replacing an existing technology that a company is already using (Elasticsearch v.s Solr for example) the questions I ask are:
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.
> 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
Sigh... just yesterday I found code in a project I inherited where an Observable was returning Futures to the observer. It probably seemed like a good idea to whoever at the time but damn does it make it hard to follow what’s going on.
It's basically never worth replacing the old stuff. Only adopt new stuff if the future use cases are so huge (10x the old system) that the old stuff becomes a small afterthought that you can easily afford to throw it away (and lose its value) or pay the cost of rewriting it (which mostly cancels out it's value)
> Sometimes there’s a technology that solves a problem really well in your particular project, but which is really hard to understand or learn.
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.
One of my favourite observations about Python is that it's the second best language for basically everything - which makes it a fantastic default for an organization.
Any good pointers to some of their technical blogs about this?
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).
Never thought about it that way, but it's an interesting observation.
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.
Yes, you quite often see facepalm solutions.
For example,
In the java world, they cooked up something called 'ant' which was a description in xml that would be parsed and interpreted by a java program to do all kinds of shell stuff (like creating directories, moving files, compiling files, ....).
Obviously, this is a poor man's interpreter, and python would have been a better choice, or probably something like make, or scons, or whatever. I'm not doing java anymore, but I'm pretty sure some people still use it.
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.
Ant (and yeah the ecosystem has moved moved on since you left) is obviously not an interpreter and was never intended to be one. Neither are the more currently popular build tools.
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.
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.
I guess I was unclear. It's not about language choice.
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.
A big one for me is “What is the community like?”. Especially for open source technologies. Do the contributors spend time answering questions? What is the general tone in the community, welcoming? Confrontational?
All the best technology decisions I have made have come with a strong friendly community.
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.