Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Let's Rewrite Everything

martinpeck.com

Post reply on HN
Print view View original

31–40 of 61 posts

Re: Let's Rewrite Everything

#31

Post by tinco »

aspaviento wrote: post #28
tialaramex wrote: post #23

Earlier quoted context omitted.

I have participated in a handful of rewrites. Most of them were indeed unnecessary or harmful. However, "X2" was definitely an example of an appropriate rewrite. It had the following conditions: * The existing code "X" was the product of an early-phase startup which hadn't yet figured out what it was going to do. "X" already existed at the point we were still asking questions like, "Who is the customer?" with possibl…

May I ask you something? In your experience, how would you approach the rewriting of an application with a mix of front end and back end code, bloated code from years of patches without any planning for a maintainable design (full of unused/buggy classes/methods/features), lack of tests and barely any documentation explaining its processes?

Well you're not asking me but this is a forum so off I go anyways. This can only be done with serious investment, so you need to ask your management if they are serious about the long term future of your product. If they are there's basically two options.

The first option is to develop an API layer over your old system, that is supported by a full integration test suite, and then either build a new frontend using that API, or port the old frontend over to that new API. As this effort progresses, your integration test suite and well defined API allow you to replace/rewrite portions of your backend as well.

The second option is to look at your most valuable customers, discern what features they use and rely on, and design a fully separate clean slate implementation of only those features in a new "V2" product.

In either case, what you're describing is a very tough situation, and any solution would be very risky. Management usually is not aware of tech debt, they might not know they've accrued a million dollars or more of engineering debt that they will have to pay off to solve problems like being able to quickly respond to new market developments, retaining high quality engineers or ballooning customer dissatisfaction.

Re: Let's Rewrite Everything

#32

Post by robert_dipaolo »

eternityforest wrote: post #11
tinco wrote: post #6

This is madness. There's no real advice about rewrites in this article. The reality of rewrites is that they often fail, cost a ridiculous amount of time and effort, don't actually fix the original problem and/or bankrupt the company. You can't just wave away those realities with "think about the downsides". I have participated in a few (small) rewrites that were successful, and this would be my advice: Don't rewrite…

I'm convinced that bad rewrites happen because coders get bored and care more about the possibility of a little bit better code, then the whole future of the company. Necessary rewrites happen because they did too much YAGNI thinking in version 1.

For anyone else who was wondering what YAGNI is, You Ain't Gonna Need It - https://martinfowler.com/bliki/Yagni.html

Re: Let's Rewrite Everything

#33

Post by xwolfi »

aspaviento wrote: post #28
tialaramex wrote: post #23

Earlier quoted context omitted.

I have participated in a handful of rewrites. Most of them were indeed unnecessary or harmful. However, "X2" was definitely an example of an appropriate rewrite. It had the following conditions: * The existing code "X" was the product of an early-phase startup which hadn't yet figured out what it was going to do. "X" already existed at the point we were still asking questions like, "Who is the customer?" with possibl…

May I ask you something? In your experience, how would you approach the rewriting of an application with a mix of front end and back end code, bloated code from years of patches without any planning for a maintainable design (full of unused/buggy classes/methods/features), lack of tests and barely any documentation explaining its processes?

Not the OP you're asking the question to, but I was in exactly his case. I hate rewrites and joined a new company (this was 5 years ago) that was failing their rewrite(6 months in, 4 "verticals" to port, only half-way the first one). The original code was a PHP/JS mess done in the Philippines that worked but was insanely awkward to change/deploy/monitor: think all the fad you learn at uni about micro service/design pattern/latest devops but no experience to tie it all in in a logical way - which is fine, startup, successful nonetheless, VERY cheap devs yet motivated.

So, the rewrite was a failure because the new team was smug, very smug. They were in Hong Kong, elites of Asia, trying to rework the "shit" done by the remote guys, and so they... well they over-engineered a monster from scratch in Grails (argl, I nearly died, having joined to do Java), and were hitting the limits of their Grails abilities (no tools, no debugger, no experience, no support, a new version just out the month before they started that change all documented paradigms, an architect who only wanted Grails and nothing else and didn't care whether the product did anything or not).

So well the thing we did to eventually move the mess to production (so we have a dying Philippino software we can't maintain because we fired all the devs there prematurely ofc, and a 25% done product in a state that's going to the wall even faster than the old one):

- Unsmug the team: teach them Grails (sadly, I was... the most experienced grails developer myself, against my will, having been a victim of it in all my previous jobs), isolate the most damaging devs

- Re-hire the PH team and move them to Hong Kong to fully maintain the old software, for 2 years, while they also learned Grails and moved to the new system with their precious new skill (they never thanked us, weird)

- Learn the old system: respect its decision algorithm that were not simple, understand why it was slow/ugly/messy whatever, rather than say it's because the devs were inferiors: we slowly realized they were not

- Slow move everything to the simplest possible technology rather than beautiful one-pager bullshit like Grails or Angular or whatever.

So my advice to you is: embrace the fact you will not do better. You will do worse or the same. Rewrite for a business reason, and if possible smaller parts. Do not be so smug as to say "bloated code" or "without any planning for a maintanable design". All it takes is 2 months of money making pressure to entirely destroy any code base, and guess what, people will want your software to make money, not just be beautiful.

Re: Let's Rewrite Everything

#34

Post by aliswe »

vkou wrote: post #8
QuadrupleA wrote: post #5

A classic Joel Spolsky post along these lines: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

A classic Joel Spolsky post that completely failed to take into account the fact that Netscape rewrote itself into Mozilla, which then went on to eat IE5's lunch.

didn't the rewrite take 8 whopping years? if that is true id argue no one's lunch got eaten.

Re: Let's Rewrite Everything

#35

Post by bazoom42 »

eternityforest wrote: post #11
tinco wrote: post #6

This is madness. There's no real advice about rewrites in this article. The reality of rewrites is that they often fail, cost a ridiculous amount of time and effort, don't actually fix the original problem and/or bankrupt the company. You can't just wave away those realities with "think about the downsides". I have participated in a few (small) rewrites that were successful, and this would be my advice: Don't rewrite…

I'm convinced that bad rewrites happen because coders get bored and care more about the possibility of a little bit better code, then the whole future of the company. Necessary rewrites happen because they did too much YAGNI thinking in version 1.

And for the simple reason it is easier and more fun to write code than to read code.

Re: Let's Rewrite Everything

#36

Post by aspaviento »

xwolfi wrote: post #33
aspaviento wrote: post #28

Earlier quoted context omitted.

May I ask you something? In your experience, how would you approach the rewriting of an application with a mix of front end and back end code, bloated code from years of patches without any planning for a maintainable design (full of unused/buggy classes/methods/features), lack of tests and barely any documentation explaining its processes?

Not the OP you're asking the question to, but I was in exactly his case. I hate rewrites and joined a new company (this was 5 years ago) that was failing their rewrite(6 months in, 4 "verticals" to port, only half-way the first one). The original code was a PHP/JS mess done in the Philippines that worked but was insanely awkward to change/deploy/monitor: think all the fad you learn at uni about micro service/design p…

I'm not trying to disrespect anyone's work. I'm just describing a situation. There are smart pieces of code there that solved the problems that were presented at each time with more/less time to work on them but poorly glued together. Similar problems were solved in completely different ways which makes the application less homogenic and requires to apply an extra effort to understand what's happening on each place. Lack of refactoring and tests left a lot of unused/unstable code that is only noticed when accessing specific areas/features of the application.

I understand the effects of time constraints and respect the years of dedications the developers gave to the application but that doesn't make the situation any more pretty.

Re: Let's Rewrite Everything

#37

Post by wokwokwok »

> “If I replace all of this Python code with Go it’ll be SO much faster!”

I write a lot of python, and the irony of this comment is that it’s probably true.

Worth the cost and time and effort? /shrug

Easier and faster to keep implementing features in? /shrug

…but out and out faster to build, deploy and run?

Yep, probably.

Im my experience python applications are slow it’s usually because your user logic is heavily implemented in python, and despite alllll the hand waving, that is, in general still slow. The package manger is slow and broken. It’s painful to deploy.

You can probably solve the problem in other ways, by picking parts to move to another language that provides an easy way to expose python bindings… but you know.

Make it faster by rewriting in go will probably work, if you only goal is “runs faster”.

Re: Let's Rewrite Everything

#38

Post by tsimionescu »

tinco wrote: post #6

This is madness. There's no real advice about rewrites in this article. The reality of rewrites is that they often fail, cost a ridiculous amount of time and effort, don't actually fix the original problem and/or bankrupt the company. You can't just wave away those realities with "think about the downsides". I have participated in a few (small) rewrites that were successful, and this would be my advice: Don't rewrite…

I think the only way to end up with a successful re-write is to be extremely realistic with the whole organization about the scope.

For a program that took 10 years to develop, a rewrite will probably take around 10 years as well to reach feature parity. Obviously, if you stop development on your successful app for 10 years waiting for the rewrite, you will fail. If you think 10 years worth of work can now be finished in 2 years with the benefit of hindsight, you will fail.

But, if you start your new app by first attacking new markets that the old one couldn't, so that the new app is genuinely valuable in itself, and then you slowly consolidate it by adding features that the old app had, while still maintaining a crew developing the old app as needed to address the existing markets, you can justify the investment and then some. Of course, this should only be done if it has become clear that the old program is really not possible/worth it to extend and continue in the long run, which can happen for various reasons.

There will be times where you will find massive shortcuts you can take, since odds are things you had to develop from scratch 10 years ago exist pre-packaged today. You may also be able to re-use parts of the old app that were actually in good shape and take them whole. But you should never rely on these things making your work shorter - they are nice boons, but the correct estimate is still in the order of magnitude of the old app.

Re: Let's Rewrite Everything

#39

Post by bvrmn »

hw wrote: post #7

Had met my share of engineers who wanted to rewrite everything from scratch into microservices and the reason they gave was ‘well microservices scales and monoliths dont’ - without taking into account the maturity of the existing application, the scale it already operates at and the scale we expect to operate at, the team resources and skills to required to support the rewrite, and the business requirements and goals…

> well microservices scales and monoliths dont'

The world we live now in. It's not funny anymore.

Re: Let's Rewrite Everything

#40

Post by aspaviento »

tinco wrote: post #31
aspaviento wrote: post #28

Earlier quoted context omitted.

May I ask you something? In your experience, how would you approach the rewriting of an application with a mix of front end and back end code, bloated code from years of patches without any planning for a maintainable design (full of unused/buggy classes/methods/features), lack of tests and barely any documentation explaining its processes?

Well you're not asking me but this is a forum so off I go anyways. This can only be done with serious investment, so you need to ask your management if they are serious about the long term future of your product. If they are there's basically two options. The first option is to develop an API layer over your old system, that is supported by a full integration test suite, and then either build a new frontend using tha…

Thank you for your feedback. I'm also in favour of unentangled frontend from backend as a first step. Problem here is that the frontend needs to be rebuilt in a different language and $boss wants to keep releasing new versions during the rewriting (obviously) so porting the old frontend allows to release new versions but doubles the time for the rewriting while building a new frontend would leave the customers without new updates for a long time.
Post reply on HN