4 ms·

My favorite genre of this is the guys proposing Greenfield rewrites of a multi-decade old app, using some tech less than 1 year old. Turns out brand new stuff

My favorite genre of this is the guys proposing Greenfield rewrites of a multi-decade old app, using some tech less than 1 year old. Turns out brand new stuff doesn't always survive, and even if it does you don't know its tradeoffs & pain points yet. Everything is perfect & bug-free when it has no product use. Seen it many times, and seen the wreckage later.

Spivak 2y ago
Being charitable, in order for one of those new technologies to become mature and boring it requires guys like that to actually use it for things. So while it might be misguided we thank them for their sacrifice of getting caught on every sharp edge so they might be dulled (or at least documented) later.
- steveBK123 2y ago
  Oh yeah, SOMEONE has to be be first. It just doesn't have to be YOU! If you want to be successful in your career, when you are put in charge of a big new project, on a tight timeline, high management visibility, etc.. you dig into your existing tried & true toolkit to get the job done. There's so many other variables, why needlessly add more risk no one asked for? But yes, I'm glad there are maniacs out there.. I just don't want to work with them.
  - eirikbakke 2y ago
    Ideally, framework code originates from some existing, working product, from which it was factored out because it happened to be useful. Contrast this with frameworks that are created for the framework's own sake, hoping to attract its first application developers.
    - WesolyKubeczek 2y ago
      Granted, I remember symfony was very good, even in versions 1.x. It truly made working with PHP not suck as much as it did back in the day. I don't remember if there was ever a product of which it was born.
  - notjoemama 2y ago
    > you dig into your existing tried & true toolkit to get the job done Haha. Yes. But when the c-suite is made up of top level management pushed out of the s&p 500, they always assume it’s their tried and true toolkit from another company. Believe me, it’s never the hammer the current engineering staff is holding. I’m slow clapping so hard for the business school graduates right now…
- hylaride 2y ago
  And if the new tech is beneficial and adds enough value that it makes it worth replacing the old tech, then by all means go for it. However, I can't count many companies I've seen decide to get into "the cloud" only to do lift-and-shifts and are now running their stack in slower and more expensive ways. There's a reason this youtube video exists and it's because people get into hype and then are saddled with technical debt: https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs Over the last decade I worked for a fintech that did analytics for the investment banking industry and between 2016-2020 the amount of people that were shocked we weren't trying to shove blockchain somewhere was surreal.
  - whstl 2y ago
    I totally agree with you, but it’s funny that you use the cloud as the non-boring example here. I’m pretty sure the majority of HN thinks that even hosting directly on EC2 is for NIH adventurers only.
    - hylaride 2y ago
      Yeah, it was an example for when it was fashionable.
  - teemur 2y ago
    Oh, that video brought memories. I wonder if there is any good content about low code fallacy or cloud?
ffsm8 2y ago
Your phrasing implies that the Greenfield rewrite is always a mistake. Depending on the project, it might actually be the only sane option if you're still required to make significant changes to the application and features have be be continuously added - and the project has already become so full of technical debt that even minor changes such as mapping an additional attribute can take days. As an easily explained example for such: I remember an angular fronted I had to maintain a while ago. The full scope of the application was to display a dynamic form via multiple inputs and interdependent on the selected choices of the available form (so if question 1 had answer a, question 2+3 had to be answered etc). While I wouldn't call such a behavior completely trivial, on a difficulty line it was definitely towards the easy end - but the actual code was so poorly written that any tiny change always led to regressions. It was quite silly that we weren't allowed to invest the ~2 weeks to recreate it Another example that comes to mind is a backend rewrite of a multi million PHP API to a Java backend. They just put the new Java backend in front of the old API and proxied through while they implemented the new routes. While it took over 2 years in total, it went relatively well. But yeah, lots of Greenfield rewrites end in disaster. I give you that!
- steveBK123 2y ago
  I am talking about real multi-year Greenfield projects, not 2 week rewrites. You are describing a web form. If something is a 2 week rewrite, write it in BASIC, write it in a language you invented, whatever, have fun.
  - monsieurbanana 2y ago
    > Another example that comes to mind is a backend rewrite of a multi million PHP API to a Java backend. They just put the new Java backend in front of the old API and proxied through while they implemented the new routes. While it took over 2 years in total, it went relatively well. Their next example was exactly what you asked for, 2 years rewrite. Bonus points from me because they didn't wait for the whole rewrite to be done, and instead started using the new project by replacing only parts of the original one.
    - 2y ago
cbozeman 2y ago
> Greenfield rewrites of a multi-decade old app It depends on what you mean by "multi-decade old app". Excel is a multi-decade old app. Windows is a multi-decade old app. They're both still being actively developed with a lot of new and cool features added though, and that keeps it fresh. The multi-decade old app that hasn't been touched in 20 years? It need a rewrite. And yesterday. I suspect though, that is not what you meant.
- steveBK123 2y ago
  I've seen projects akin to "Excel sucks because its written in X, I am very smart, we will rewrite it to run in browser only with this new framework I read about, backed by microservices in Kotlin/Rust/some new fad, running server less on AWS (using this new thing thats just out of beta that I saw at re:Invent)". And we need to stop all new feature work on Excel since its legacy, so give me 80% of the dev team to do above. Oh btw, they don't know the alphabet soup of stuff I decided to use, so we will also start firing them as well, as I need to hire for these special skills.
  - bluGill 2y ago
    Eventually you need to admit COBOL is dead and rewrite. Eventually some library/framework is dead and you need to rewrite. However there are lots of options, and often your best is in place rewrite just small parts at a time, slowly getting rid of the legacy code over a couple decades - there is no real hurry here. Eventually styles will change and you will have to redo the UI. This will happen much more often than the above. Your program may look very different but if you have a good architecture this is a superficial change. It may still be expensive, but none of your core logic changes. Normally you keep the old and new UI running side by side (depending on the type of program may be different builds, other times it is just a front end) until you trust the new one. (depending on details it may be an all at once switch or one screen/widget at a time)
    - motorest 2y ago
      > Eventually you need to admit COBOL is dead and rewrite. What does that suppose to mean To frame your argument, TIOBE ranks COBOL as the 19th most popular language, ahead of Ruby.
woliveirajr 2y ago
Remembers me of https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... : "All new source code! As if source code rusted."
- efnx 2y ago
  It does rot though, as an apparent effect of everything else changing around it.
  - jay_kyburz 2y ago
    This is why I won't build on anybody else's platform ever again. From now on I'm building on boring tech I can deploy on any machine.
- dnel 2y ago
  A 25 year old article that might as well have been written yesterday, clearly stood the test of time.
- stevoski 2y ago
  The irony is that Joel’s “FogBugz” product eventually got rewritten many years later.
  - robocat 2y ago
    Not ironic. Capable people know the constraints (and perhaps write good articles about them) and they know when to break those rules. Good engineering is making the right compromises.
- gregors 2y ago
  It would be good to remember Joel did a complete rewrite and blogged about it. https://www.joelonsoftware.com/2002/04/11/our-net-strategy/ https://www.joelonsoftware.com/2002/04/11/our-net-strategy/ The idea isn't that you can't rewrite in a new language, it's that want to do bit by bit. Don't just to the big bang thing.
swat535 2y ago
I experienced this few years ago. I was hired with a team of consultants (I know.. I know..) because the system in question would have data randomly disappear from their databases every few weeks and it would take the operation team a month to notice, so by then the issue was harder to rectify. The engineering team in question had proposed to rewrite an old Java app with AWS Amolify and replace their Postgres database with Dynodb. The whole thing was then ducktaped with Lambdas and spread across multiple regions. They had not bothered writing a single line of test, never mind having any kind of build and deployment pipeline.. they didn’t even have basic error reporting. After doing a deeper dive, we discovered that engineers didn’t have a local environment but only had access to staging, however they could easily connect to the production database from local by just updating environmental variables. It turns out that one of them had forgotten to switch it back after debugging something on production from his machine and had forgotten to switch it back.. he had a background cleanup job running in intervals which was wiping data.. It was a complete nightmare, the schema less nature of Dynamo made it harder to understand what is happening and the React UI would crash every 15 minutes due to an infinite loop. The operation team had learned to use the Chrome console and clear the local storage manually before the window feeezes..
bigiain 2y ago
I can, off the top of my head, name at least half a dozen of "those guys" and describe in detail the wreckage they left behind. Including one that was a major contributor to an 80%-of-the-billings client finding an alternative agency resulting in almost 100 people losing their jobs. :sigh:

Spivak 2y ago

Being charitable, in order for one of those new technologies to become mature and boring it requires guys like that to actually use it for things. So while it might be misguided we thank them for their sacrifice of getting caught on every sharp edge so they might be dulled (or at least documented) later.

steveBK123 2y ago
Oh yeah, SOMEONE has to be be first. It just doesn't have to be YOU! If you want to be successful in your career, when you are put in charge of a big new project, on a tight timeline, high management visibility, etc.. you dig into your existing tried & true toolkit to get the job done. There's so many other variables, why needlessly add more risk no one asked for? But yes, I'm glad there are maniacs out there.. I just don't want to work with them.
- eirikbakke 2y ago
  Ideally, framework code originates from some existing, working product, from which it was factored out because it happened to be useful. Contrast this with frameworks that are created for the framework's own sake, hoping to attract its first application developers.
  - WesolyKubeczek 2y ago
    Granted, I remember symfony was very good, even in versions 1.x. It truly made working with PHP not suck as much as it did back in the day. I don't remember if there was ever a product of which it was born.
- notjoemama 2y ago
  > you dig into your existing tried & true toolkit to get the job done Haha. Yes. But when the c-suite is made up of top level management pushed out of the s&p 500, they always assume it’s their tried and true toolkit from another company. Believe me, it’s never the hammer the current engineering staff is holding. I’m slow clapping so hard for the business school graduates right now…
hylaride 2y ago
And if the new tech is beneficial and adds enough value that it makes it worth replacing the old tech, then by all means go for it. However, I can't count many companies I've seen decide to get into "the cloud" only to do lift-and-shifts and are now running their stack in slower and more expensive ways. There's a reason this youtube video exists and it's because people get into hype and then are saddled with technical debt: https://www.youtube.com/watch?v=b2F-DItXtZs https://www.youtube.com/watch?v=b2F-DItXtZs Over the last decade I worked for a fintech that did analytics for the investment banking industry and between 2016-2020 the amount of people that were shocked we weren't trying to shove blockchain somewhere was surreal.
- whstl 2y ago
  I totally agree with you, but it’s funny that you use the cloud as the non-boring example here. I’m pretty sure the majority of HN thinks that even hosting directly on EC2 is for NIH adventurers only.
  - hylaride 2y ago
    Yeah, it was an example for when it was fashionable.
- teemur 2y ago
  Oh, that video brought memories. I wonder if there is any good content about low code fallacy or cloud?

ffsm8 2y ago

Your phrasing implies that the Greenfield rewrite is always a mistake. Depending on the project, it might actually be the only sane option if you're still required to make significant changes to the application and features have be be continuously added - and the project has already become so full of technical debt that even minor changes such as mapping an additional attribute can take days. As an easily explained example for such: I remember an angular fronted I had to maintain a while ago. The full scope of the application was to display a dynamic form via multiple inputs and interdependent on the selected choices of the available form (so if question 1 had answer a, question 2+3 had to be answered etc). While I wouldn't call such a behavior completely trivial, on a difficulty line it was definitely towards the easy end - but the actual code was so poorly written that any tiny change always led to regressions. It was quite silly that we weren't allowed to invest the ~2 weeks to recreate it Another example that comes to mind is a backend rewrite of a multi million PHP API to a Java backend. They just put the new Java backend in front of the old API and proxied through while they implemented the new routes. While it took over 2 years in total, it went relatively well. But yeah, lots of Greenfield rewrites end in disaster. I give you that!

steveBK123 2y ago
I am talking about real multi-year Greenfield projects, not 2 week rewrites. You are describing a web form. If something is a 2 week rewrite, write it in BASIC, write it in a language you invented, whatever, have fun.
- monsieurbanana 2y ago
  > Another example that comes to mind is a backend rewrite of a multi million PHP API to a Java backend. They just put the new Java backend in front of the old API and proxied through while they implemented the new routes. While it took over 2 years in total, it went relatively well. Their next example was exactly what you asked for, 2 years rewrite. Bonus points from me because they didn't wait for the whole rewrite to be done, and instead started using the new project by replacing only parts of the original one.
  - 2y ago

cbozeman 2y ago

> Greenfield rewrites of a multi-decade old app It depends on what you mean by "multi-decade old app". Excel is a multi-decade old app. Windows is a multi-decade old app. They're both still being actively developed with a lot of new and cool features added though, and that keeps it fresh. The multi-decade old app that hasn't been touched in 20 years? It need a rewrite. And yesterday. I suspect though, that is not what you meant.

steveBK123 2y ago
I've seen projects akin to "Excel sucks because its written in X, I am very smart, we will rewrite it to run in browser only with this new framework I read about, backed by microservices in Kotlin/Rust/some new fad, running server less on AWS (using this new thing thats just out of beta that I saw at re:Invent)". And we need to stop all new feature work on Excel since its legacy, so give me 80% of the dev team to do above. Oh btw, they don't know the alphabet soup of stuff I decided to use, so we will also start firing them as well, as I need to hire for these special skills.
- bluGill 2y ago
  Eventually you need to admit COBOL is dead and rewrite. Eventually some library/framework is dead and you need to rewrite. However there are lots of options, and often your best is in place rewrite just small parts at a time, slowly getting rid of the legacy code over a couple decades - there is no real hurry here. Eventually styles will change and you will have to redo the UI. This will happen much more often than the above. Your program may look very different but if you have a good architecture this is a superficial change. It may still be expensive, but none of your core logic changes. Normally you keep the old and new UI running side by side (depending on the type of program may be different builds, other times it is just a front end) until you trust the new one. (depending on details it may be an all at once switch or one screen/widget at a time)
  - motorest 2y ago
    > Eventually you need to admit COBOL is dead and rewrite. What does that suppose to mean To frame your argument, TIOBE ranks COBOL as the 19th most popular language, ahead of Ruby.

woliveirajr 2y ago

Remembers me of https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-... : "All new source code! As if source code rusted."

efnx 2y ago
It does rot though, as an apparent effect of everything else changing around it.
- jay_kyburz 2y ago
  This is why I won't build on anybody else's platform ever again. From now on I'm building on boring tech I can deploy on any machine.
dnel 2y ago
A 25 year old article that might as well have been written yesterday, clearly stood the test of time.
stevoski 2y ago
The irony is that Joel’s “FogBugz” product eventually got rewritten many years later.
- robocat 2y ago
  Not ironic. Capable people know the constraints (and perhaps write good articles about them) and they know when to break those rules. Good engineering is making the right compromises.
gregors 2y ago
It would be good to remember Joel did a complete rewrite and blogged about it. https://www.joelonsoftware.com/2002/04/11/our-net-strategy/ https://www.joelonsoftware.com/2002/04/11/our-net-strategy/ The idea isn't that you can't rewrite in a new language, it's that want to do bit by bit. Don't just to the big bang thing.

swat535 2y ago

I experienced this few years ago. I was hired with a team of consultants (I know.. I know..) because the system in question would have data randomly disappear from their databases every few weeks and it would take the operation team a month to notice, so by then the issue was harder to rectify. The engineering team in question had proposed to rewrite an old Java app with AWS Amolify and replace their Postgres database with Dynodb. The whole thing was then ducktaped with Lambdas and spread across multiple regions. They had not bothered writing a single line of test, never mind having any kind of build and deployment pipeline.. they didn’t even have basic error reporting. After doing a deeper dive, we discovered that engineers didn’t have a local environment but only had access to staging, however they could easily connect to the production database from local by just updating environmental variables. It turns out that one of them had forgotten to switch it back after debugging something on production from his machine and had forgotten to switch it back.. he had a background cleanup job running in intervals which was wiping data.. It was a complete nightmare, the schema less nature of Dynamo made it harder to understand what is happening and the React UI would crash every 15 minutes due to an infinite loop. The operation team had learned to use the Chrome console and clear the local storage manually before the window feeezes..

bigiain 2y ago

I can, off the top of my head, name at least half a dozen of "those guys" and describe in detail the wreckage they left behind. Including one that was a major contributor to an 80%-of-the-billings client finding an alternative agency resulting in almost 100 people losing their jobs. :sigh: