When a development team introduces new technology to solve a problem, they are adding a long term cost, too, even though it may not be obvious. This is one way that a technical decision is a business decision.
Last week I was speaking to a friend about Erlang, a technology designed in the telecoms sector to allow easy development of very highly available systems. He said he’d worked in a bank where they needed their systems to be similarly available. Erlang’s model was perfect for them.
However his managers didn’t want to introduce Erlang. All their systems were written in C++, and they didn’t want to deviate from that. My friend’s team ended up rebuilding the architecture of the Erlang platform in C++. It was very time-consuming, but it worked—of course, because it was based on a proven model. They got something that was as reliable as Erlang, but in C++.
Some people might think this insistence on rebuilding a proven system was a waste of time and a bad decision. However my friend didn’t—or at least, he doesn’t now. And I agree. Building the software takes a relatively short time compared to how long it needs to be maintained. The operations team would need to size and build machines based on different metrics to their other systems; future developers would have to be hired with different skillsets, and they’d be limited to working only on that system; any other developers, skilled in C++, would be unable support the Erlang system; support people would be limited in their ability to understand and troubleshoot the new system.
Less technology is better. Introducing a new technology is not just a technical decision; it has a long term operational cost for the business, too.
niksilver.com 