3 ms·

> Do you know any? Generally, if you get to the point where you have to scour the internet to cherry-pick positive stories, it's not a good sign. In these sit

> Do you know any? Generally, if you get to the point where you have to scour the internet to cherry-pick positive stories, it's not a good sign. In these situations, you shouldn't be asking if success stories exist. It's a big world out there, so you're bound to find a success story somewhere. The real question is how likely it is to succeed, and at what cost? I worked at a company that did a somewhat successful rewrite, although it came at a cost. In retrospect, the rewrite helped us get rid of some problems we knew we had, but it introduced a large number of new problems we didn't see coming. It also cost us the better part of a year just getting back to feature parity with the original product. From a product perspective, that time would have been better spent working on new features.

pedalpete 6y ago
In addition to this, there are all the horror stories of re-writes being a waste of resources. I've done it myself, and wish I hadn't. Having said that, I think this is one of the great benefits of micro-service architecture. You can re-write piece by piece as you add functionality or create a measure of improvement. But don't use the "we need to write this as micro-services" as an argument. You say "re-write large parts", so I assume that means not the whole thing, and not a new language. If that is the case, I'd suggest tackling the "re-write" as a piece by piece upgrade rather than a re-write, and look for a business case for each component you plan on re-writing. The engineer wants a beautiful system, the business wants a system that works. The business pays the engineer. So buy "selling" the business the benefits of specific improved functionality, you may get a new beautiful system. Is there a part of the system that is particularly expensive part of the app from a services (DB, API requests, etc) stand-point? Can you quantify for the business the benefit they'd get from re-writing that part of the app, and the cost savings they'd expect to get? If you're close with the design team (which I hope you are, or suggest you become), are there business goals they are designing for which would allow you to sandbox a part of the app to be re-written? Do that 20 times, and you've got a new app, and you didn't do a 're-write', you just kept adding great functionality and cleaning up as you went. So, I'd suggest getting the idea of a 're-write' out of your head, and instead approach it from a "how can we improve this tiny piece of the app while pushing the business forward".
username90 6y ago
Rewrites succeeding is the expected outcome, only articles of when they resulted in a catastrophe will bubble up. Typical scenario: A team rewrites their code, they succeed, nobody notices since things are still running, end of story.

pedalpete 6y ago

In addition to this, there are all the horror stories of re-writes being a waste of resources. I've done it myself, and wish I hadn't. Having said that, I think this is one of the great benefits of micro-service architecture. You can re-write piece by piece as you add functionality or create a measure of improvement. But don't use the "we need to write this as micro-services" as an argument. You say "re-write large parts", so I assume that means not the whole thing, and not a new language. If that is the case, I'd suggest tackling the "re-write" as a piece by piece upgrade rather than a re-write, and look for a business case for each component you plan on re-writing. The engineer wants a beautiful system, the business wants a system that works. The business pays the engineer. So buy "selling" the business the benefits of specific improved functionality, you may get a new beautiful system. Is there a part of the system that is particularly expensive part of the app from a services (DB, API requests, etc) stand-point? Can you quantify for the business the benefit they'd get from re-writing that part of the app, and the cost savings they'd expect to get? If you're close with the design team (which I hope you are, or suggest you become), are there business goals they are designing for which would allow you to sandbox a part of the app to be re-written? Do that 20 times, and you've got a new app, and you didn't do a 're-write', you just kept adding great functionality and cleaning up as you went. So, I'd suggest getting the idea of a 're-write' out of your head, and instead approach it from a "how can we improve this tiny piece of the app while pushing the business forward".

username90 6y ago

Rewrites succeeding is the expected outcome, only articles of when they resulted in a catastrophe will bubble up. Typical scenario: A team rewrites their code, they succeed, nobody notices since things are still running, end of story.