4 ms·

Just rewrite the dang thing! Planned obsolescence is so important for all of these reasons listed in this article. Know when its time to kill your services, a

Just rewrite the dang thing! Planned obsolescence is so important for all of these reasons listed in this article. Know when its time to kill your services, and have a plan well in advance for how it'll go down, and what will take its place.

tluyben2 6y ago
For very large codebases, this is often not an option. I know of very large 'let's write Cobol mainframe to Java' projects, burning 10s of millions of euros, that were just thrown away because they could not actually get it working in the end. And this is not limited to mainframe projects; it happens with (large) more recent projects (Java/C# mostly) as well.
- TameAntelope 6y ago
  For sure, it's not an option for these existing systems. But when building a new system, design it and plan for it to be retired when certain criteria are met (e.g. when it hits 100 reqs/sec, 3 years from first release, when LOC hits 100k).
  - tluyben2 6y ago
    Absolutely: I was only commenting on a blind 'just rewrite it' as that will always be the first reaction of tech people and quite often it is simply not feasible. But agreed, by design it can work.
- barbarbar 6y ago
  That raises an interesting question. Are there any such rewrites that have succeeded? I have mainly heard that it is either failures or not done.
  - TameAntelope 6y ago
    If you are asking me if I’ve experienced a successful rewrite? Yes, numerous, and the more successful ones have happened as a result of planning. I’ve also been part of rewrites that have gone poorly, due to a lack of planning, where the legacy software fails in unexpected and unanticipated ways, which requires a rushed attempt to fix the issue (which fails) and a subsequent rushed attempt to replace the core functionality when the fix doesn’t work (and also fails because “core” tends to be larger than you initially think). Knowing ahead of time when software isn’t going to be useful any more isn’t really an option, it’s just an acceptance of what is already going to happen.
astura 6y ago
This is the worst idea I ever heard. This only "works" for companies that have unlimited VC funds to light on fire, for companies who have to actually make money, this is in no way something you can do. This is the equivalent of bulldozing your house and building another because your hot water heater broke.
- TameAntelope 6y ago
  It works for every company who has software they maintain, and while I’m sorry you don’t think it’s a good idea, I think the issue is more with your lack of understanding than the idea itself. Specifically, your analogy to construction is a bad one - software is not construction, and one critical difference is the cost of rebuilding is many orders of magnitude cheaper. When you include the reality of obsolescence into your design, you are actively anticipating and accounting for problems as they’re outlined in this article, which is always a good thing, and will always improve your planning and its outcomes. Burying your head in the sand by expecting to never have to rebuild something is very poor project management, and not how competent software shops operate, period.
  - astura 6y ago
    1) Don't apologize to me because you don't understand how business works. 2) If you need to make a profit (and NOT just light someone else's money on fire), you can't afford to just throw away your profitable product(s) and rebuild them because some devs are easily triggered prima donnas who want to whine because "legacy." That's not how business works in the real world. 3) Companies (again, the ones who must make a profit) aren't going to get clients that way. Clients invest in software because the large upfront costs and small maintenance costs will amortize over the many years they intend on using this product. They aren't going to fund rewriting the product from scratch multiple times. 4) Clients are not going to fund a rewrite ever few years because the cost of rewriting is not "many orders of magnitude cheaper," that's a complete and total fiction. I know this because I've participated in ROM estimates for clients. Of course, if your "business" has unlimited VC funds coming in then its backwards land. But most businesses exist to make a profit, not to spend someone else's money.

tluyben2 6y ago

For very large codebases, this is often not an option. I know of very large 'let's write Cobol mainframe to Java' projects, burning 10s of millions of euros, that were just thrown away because they could not actually get it working in the end. And this is not limited to mainframe projects; it happens with (large) more recent projects (Java/C# mostly) as well.

TameAntelope 6y ago
For sure, it's not an option for these existing systems. But when building a new system, design it and plan for it to be retired when certain criteria are met (e.g. when it hits 100 reqs/sec, 3 years from first release, when LOC hits 100k).
- tluyben2 6y ago
  Absolutely: I was only commenting on a blind 'just rewrite it' as that will always be the first reaction of tech people and quite often it is simply not feasible. But agreed, by design it can work.
barbarbar 6y ago
That raises an interesting question. Are there any such rewrites that have succeeded? I have mainly heard that it is either failures or not done.
- TameAntelope 6y ago
  If you are asking me if I’ve experienced a successful rewrite? Yes, numerous, and the more successful ones have happened as a result of planning. I’ve also been part of rewrites that have gone poorly, due to a lack of planning, where the legacy software fails in unexpected and unanticipated ways, which requires a rushed attempt to fix the issue (which fails) and a subsequent rushed attempt to replace the core functionality when the fix doesn’t work (and also fails because “core” tends to be larger than you initially think). Knowing ahead of time when software isn’t going to be useful any more isn’t really an option, it’s just an acceptance of what is already going to happen.

astura 6y ago

This is the worst idea I ever heard. This only "works" for companies that have unlimited VC funds to light on fire, for companies who have to actually make money, this is in no way something you can do. This is the equivalent of bulldozing your house and building another because your hot water heater broke.

TameAntelope 6y ago
It works for every company who has software they maintain, and while I’m sorry you don’t think it’s a good idea, I think the issue is more with your lack of understanding than the idea itself. Specifically, your analogy to construction is a bad one - software is not construction, and one critical difference is the cost of rebuilding is many orders of magnitude cheaper. When you include the reality of obsolescence into your design, you are actively anticipating and accounting for problems as they’re outlined in this article, which is always a good thing, and will always improve your planning and its outcomes. Burying your head in the sand by expecting to never have to rebuild something is very poor project management, and not how competent software shops operate, period.
- astura 6y ago
  1) Don't apologize to me because you don't understand how business works. 2) If you need to make a profit (and NOT just light someone else's money on fire), you can't afford to just throw away your profitable product(s) and rebuild them because some devs are easily triggered prima donnas who want to whine because "legacy." That's not how business works in the real world. 3) Companies (again, the ones who must make a profit) aren't going to get clients that way. Clients invest in software because the large upfront costs and small maintenance costs will amortize over the many years they intend on using this product. They aren't going to fund rewriting the product from scratch multiple times. 4) Clients are not going to fund a rewrite ever few years because the cost of rewriting is not "many orders of magnitude cheaper," that's a complete and total fiction. I know this because I've participated in ROM estimates for clients. Of course, if your "business" has unlimited VC funds coming in then its backwards land. But most businesses exist to make a profit, not to spend someone else's money.