3 ms·

> make sure the people using throwaway code understand that even though it kind of looks like it works, it cannot be maintained and must be rewritten I couldn'

> make sure the people using throwaway code understand that even though it kind of looks like it works, it cannot be maintained and must be rewritten I couldn't agree more with this. Not that long ago I inherited a project which on the surface looked shiny and nice. I was however aware that it was a mess underneath. Mind you, I was completely unprepared for the utter crap that awaited me. In all fairness it is the worst thing I have ever seen by light years. It took me two almost 2 weeks to find where a bug was coming from (it was written in a way which no debugger could trace it back, no logs, everything was surprised). After fixing it eventually, I decided to scrap it and build the whole thing from scratch. At the end it took me just over a month (Saturdays and Sundays included) and another 2 weeks from another developer to get a replacement project from an empty file. And here are the two painful truths about the whole endeavour: it took us collectively under two months to build, document, test, and run it in production. A grand total of around 20-30k lines of code. It took the people before us 3 and a half years to make their version which was anti patterns, top to bottom and in those 3 years the company invested around half a million Euros in salaries alone. If argue that this is the most painful thought. Not even the fact that this has been my first weekend this year in which I'm actually relaxing and not working. So my word of advice-if you end up in a similar situation, scrap everything, do it from scratch. Take a piece of paper, write down the business logic, draw a diagram of the structure of your application around it, pick the most appropriate stack and go for it. Avoid shiny new toys, profile everything and remember that sometimes it's better to let an application crash in order to find it's weaknesses.

Swizec 7y ago
It’s easier to build something once you know what you want than it is while you’re discovering what you want. We’re dealing with similar at work now. Over 5 years a system was built. It works and the code is crap. Now I’m pushing management to please just decide “Yes, this is what we wanted all along” so we can throw out 90% of the code
- axegon_ 7y ago
  > It’s easier to build something once you know what you want than it is while you’re discovering what you want. Oh absolutely. Thing is, in my case, what was needed was clearly defined since the beginning. It's the "developers" who built it who were incompetent af.
fralewsmi 7y ago
Counter argument https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- axegon_ 7y ago
  In a perfect world, yes. In the case where someone decided to move around 12gb of data up and down 23 different classes just so they can count the objects in those 12 gb in every class, things start to change. In my case it was the latter.
- robocat 7y ago
  “ Things You Should Never Do: They decided to rewrite the code from scratch.” This is a great general rule. The rule is situation dependant and some people can break it and succeed: the parent comment was very clearly one of those situations. The actual risk is that the majority of us think we can break the rule, when it turns out we can’t. But a minority of people/situations can successfully do a complete rewrite, success defined as where the gains abundantly outweigh the pains.
  - dannypgh 7y ago
    My rule is be skeptical of anyone proposing a rewrite who doesn't fully understand the existing system, to such depth that they would feel comfortable refactoring it. Which means anytime someone says "we want to rewrite it because refactoring it is too hard" I tend to not believe them. There are times when rewrites are less total work, but they're hardly ever "easier" when you account for the cognitive load of making sure the requirements of the rewrite are being accurately captured. Maybe there's an exception if you know the requirements have been drastically simplified, but I doubt that's practically useful.

Swizec 7y ago

It’s easier to build something once you know what you want than it is while you’re discovering what you want. We’re dealing with similar at work now. Over 5 years a system was built. It works and the code is crap. Now I’m pushing management to please just decide “Yes, this is what we wanted all along” so we can throw out 90% of the code

axegon_ 7y ago
> It’s easier to build something once you know what you want than it is while you’re discovering what you want. Oh absolutely. Thing is, in my case, what was needed was clearly defined since the beginning. It's the "developers" who built it who were incompetent af.

fralewsmi 7y ago

Counter argument https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...

axegon_ 7y ago
In a perfect world, yes. In the case where someone decided to move around 12gb of data up and down 23 different classes just so they can count the objects in those 12 gb in every class, things start to change. In my case it was the latter.
robocat 7y ago
“ Things You Should Never Do: They decided to rewrite the code from scratch.” This is a great general rule. The rule is situation dependant and some people can break it and succeed: the parent comment was very clearly one of those situations. The actual risk is that the majority of us think we can break the rule, when it turns out we can’t. But a minority of people/situations can successfully do a complete rewrite, success defined as where the gains abundantly outweigh the pains.
- dannypgh 7y ago
  My rule is be skeptical of anyone proposing a rewrite who doesn't fully understand the existing system, to such depth that they would feel comfortable refactoring it. Which means anytime someone says "we want to rewrite it because refactoring it is too hard" I tend to not believe them. There are times when rewrites are less total work, but they're hardly ever "easier" when you account for the cognitive load of making sure the requirements of the rewrite are being accurately captured. Maybe there's an exception if you know the requirements have been drastically simplified, but I doubt that's practically useful.