5 ms·

A code rewrite means time spent working on stuff that isn't delivering features, which means your business could be stagnating, making customers dissatisfied, g

A code rewrite means time spent working on stuff that isn't delivering features, which means your business could be stagnating, making customers dissatisfied, giving competitors an opening. As an example, I recently migrated a Node app from MongoDB to Postgres. This ended up taking two and a half weeks, due to re-writing a fair portion of the server-side code. That's a long time to go without delivering new features or fixes. We justified it because we had inexplicable data loss (not pinpointed on MongoDB, but a poor reputation is a hard thing to remedy) and our data model did not suit a document store. But you have to then accept it when the business folks say "well, why didn't you get it right the first time? Aren't you supposed to be the expert?". As technologists, of course we find it fun to try new technologies. But outside of the main tech hubs, a large proportion of developers aren't working for tech companies whose main product consists of web services/APIs, in which case we need to always consider the costs/benefits of any tech switch. If it's not justified, you're stuck supporting flakey apps until you can move on to the next gig / learning experience.

Silhouette 12y ago
I understand where you're coming from with all of those points, but I take a different view on most of them. For example, I would argue that going a couple of weeks without delivering new features is far from a long time. If your features are so simple that they can all be added in that sort of time frame, and if failing to do so is enough for a competitor to cause serious damage to your business, then it seems unlikely that you had a strong business model/value proposition in the first place. Likewise the idea of sitting on a known and unexplained data loss bug indefinitely is horrifying. Again, if you don't consider removing that kind of liability a priority, it seems like a matter of time before something disastrous happens. Depending on the nature of your work and the data involved, this might even amount to negligence and give legitimate grounds for affected customers or regulators to take legal action. Finally, if you have management who expect everyone technical to be an expert on all technical tools and make perfect choices, then they are both ignorant of how techincal fields work and extremely poor at managing risk on a project. Once again, with that kind of person at the helm, you are already doomed. Personally I favour tried-and-tested over new-and-shiny for most projects. My experience has been that many new and trendy tools have a good sales pitch but don't stand the test of time. After using them for real for a while, developers often start to understand why things were done the way they were done before and discover that this week's silver bullet comes with limitations or risks of its own. In any case, whether you're using time-tested tools or expecting that newer really is better, building up technical debt to unmanageable levels will kill any software project. You learn as you go along, and at some stage your greater experience may suggest that a different approach would give much better results, and then you have a cost/benefit question of whether and when it's worth doing that work.
bontoJR 12y ago
Great piece. In fact, this is another big topic. I can't image a bank switching technology in a such easy way for components that maybe are critical. A technology switch can have multiple sides, sometimes the success is way beyond expectations and the current implementation doesn't fit the real requirements, making the switch looking more to a success rather than a failure. On the opposite it's very common to have the exact same problem you described, new trending technology picked, hit the limit, switch to and old more robust solution, this is definitely a failure and is something managers don't like. I faced a similar problem with Mongo 2 years ago, had the same switch to PostgreSQL.
- IndianAstronaut 12y ago
  The problem with older technologies is that their scaling capabilities are limited. My company is currently trying to use Microsoft's OLAP tool for data analysis when it should be using something more scalabke for the quantity of data we have.
  - vezzy-fnord 12y ago
    I think you're wrongly equating "old" with more undesirable epithets like "enterprise" and "proprietary". There's a ton of old technologies that scale marvelously, and using software age is a heuristic as probably really poor when you should really be studying internal qualities.
nemothekid 12y ago
As a counter-example, I recently read Twitter was built on Rails 6 months after it was released. Once the concept was proven out, and the production app was failing like crazy (fail whale everywhere) - they rewrote their entire stack in Scala/on the JVM. Now should have Twitter spent the first 6 months of their life building out the perfect infrastructure with proven tools spending the little money they had mainly on engineering or were the justified in pushing that technical debt down the road to focus on other things today. It seems to me, for most startups, that the marginal cost of building it "right" today is much higher than rewriting when you can/if you need to.
- jon-wood 12y ago
  Twitter was also originally built as a side project to amuse some friends. It wouldn't surprise me if someone took the view that they were writing a stupid little throwaway thing which everyone would probably get bored of, so why not try learning this hot new web framework everyone's talking about.
al2o3cr 12y ago
"A code rewrite means time spent working on stuff that isn't delivering features, which means your business could be stagnating, making customers dissatisfied, giving competitors an opening." On the flip side, over-engineering before launch means time spent NOT MAKING ANY MONEY because you haven't launched yet. It means pouring engineering effort into something whose success is still hypothetical. If the biz folks want to know "why didn't you get it right the first time", ask them why they didn't become millionaires at their first jobs.
- jestar_jokin 12y ago
  I absolutely think there's value in prototyping to explore business opportunities, or to evaluate choice of technology. I think problems arise when you try to do both at once. Also, once the business gets hold of a prototype, it can sometimes be hard to convince them to pay to replace the prototype with a new codebase which seemingly does exactly the same thing; after all, what they've got works, right? (For some definition of "works".) It can also be difficult to work out exactly what needs to be kept from the prototype; how do you tell what functionality is intended, and what is just a non-essential byproduct of the implementation? Yes, you can formalise the specification, but this takes time, and customers will complain about any changes to functionality. You'll be served in good stead if you pick a tech that can support all the normal boring stuff that a robust web app needs, while also providing rapid development capabilities.

Silhouette 12y ago

I understand where you're coming from with all of those points, but I take a different view on most of them. For example, I would argue that going a couple of weeks without delivering new features is far from a long time. If your features are so simple that they can all be added in that sort of time frame, and if failing to do so is enough for a competitor to cause serious damage to your business, then it seems unlikely that you had a strong business model/value proposition in the first place. Likewise the idea of sitting on a known and unexplained data loss bug indefinitely is horrifying. Again, if you don't consider removing that kind of liability a priority, it seems like a matter of time before something disastrous happens. Depending on the nature of your work and the data involved, this might even amount to negligence and give legitimate grounds for affected customers or regulators to take legal action. Finally, if you have management who expect everyone technical to be an expert on all technical tools and make perfect choices, then they are both ignorant of how techincal fields work and extremely poor at managing risk on a project. Once again, with that kind of person at the helm, you are already doomed. Personally I favour tried-and-tested over new-and-shiny for most projects. My experience has been that many new and trendy tools have a good sales pitch but don't stand the test of time. After using them for real for a while, developers often start to understand why things were done the way they were done before and discover that this week's silver bullet comes with limitations or risks of its own. In any case, whether you're using time-tested tools or expecting that newer really is better, building up technical debt to unmanageable levels will kill any software project. You learn as you go along, and at some stage your greater experience may suggest that a different approach would give much better results, and then you have a cost/benefit question of whether and when it's worth doing that work.

bontoJR 12y ago

Great piece. In fact, this is another big topic. I can't image a bank switching technology in a such easy way for components that maybe are critical. A technology switch can have multiple sides, sometimes the success is way beyond expectations and the current implementation doesn't fit the real requirements, making the switch looking more to a success rather than a failure. On the opposite it's very common to have the exact same problem you described, new trending technology picked, hit the limit, switch to and old more robust solution, this is definitely a failure and is something managers don't like. I faced a similar problem with Mongo 2 years ago, had the same switch to PostgreSQL.

IndianAstronaut 12y ago
The problem with older technologies is that their scaling capabilities are limited. My company is currently trying to use Microsoft's OLAP tool for data analysis when it should be using something more scalabke for the quantity of data we have.
- vezzy-fnord 12y ago
  I think you're wrongly equating "old" with more undesirable epithets like "enterprise" and "proprietary". There's a ton of old technologies that scale marvelously, and using software age is a heuristic as probably really poor when you should really be studying internal qualities.

nemothekid 12y ago

As a counter-example, I recently read Twitter was built on Rails 6 months after it was released. Once the concept was proven out, and the production app was failing like crazy (fail whale everywhere) - they rewrote their entire stack in Scala/on the JVM. Now should have Twitter spent the first 6 months of their life building out the perfect infrastructure with proven tools spending the little money they had mainly on engineering or were the justified in pushing that technical debt down the road to focus on other things today. It seems to me, for most startups, that the marginal cost of building it "right" today is much higher than rewriting when you can/if you need to.

jon-wood 12y ago
Twitter was also originally built as a side project to amuse some friends. It wouldn't surprise me if someone took the view that they were writing a stupid little throwaway thing which everyone would probably get bored of, so why not try learning this hot new web framework everyone's talking about.

al2o3cr 12y ago

"A code rewrite means time spent working on stuff that isn't delivering features, which means your business could be stagnating, making customers dissatisfied, giving competitors an opening." On the flip side, over-engineering before launch means time spent NOT MAKING ANY MONEY because you haven't launched yet. It means pouring engineering effort into something whose success is still hypothetical. If the biz folks want to know "why didn't you get it right the first time", ask them why they didn't become millionaires at their first jobs.

jestar_jokin 12y ago
I absolutely think there's value in prototyping to explore business opportunities, or to evaluate choice of technology. I think problems arise when you try to do both at once. Also, once the business gets hold of a prototype, it can sometimes be hard to convince them to pay to replace the prototype with a new codebase which seemingly does exactly the same thing; after all, what they've got works, right? (For some definition of "works".) It can also be difficult to work out exactly what needs to be kept from the prototype; how do you tell what functionality is intended, and what is just a non-essential byproduct of the implementation? Yes, you can formalise the specification, but this takes time, and customers will complain about any changes to functionality. You'll be served in good stead if you pick a tech that can support all the normal boring stuff that a robust web app needs, while also providing rapid development capabilities.