Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
41–50 of 704 posts
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#42Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#43First off, no, a full rewrite is not only not necessary, but probably the worst possible approach. Do a piece at a time. You will eventually have re-written all the code, but do not ever fall into the trap of a "full re-write". It doesn't work. But before you re-write once line of code - get some testing in place. Or, a lot of testing. If you have end-to-end tests that run through every feature that is currently used…
Huh. You are literally saying do a full rewrite. But it's also the worst idea? Edit: A full rewrite always meant replacing every part of a system. Whether you do it gradually doesn't really matter.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#44Earlier quoted context omitted.
Huh. You are literally saying do a full rewrite. But it's also the worst idea? Edit: A full rewrite always meant replacing every part of a system. Whether you do it gradually doesn't really matter.
Full rewrite generally means stop the presses we are gonna migrate this whole thing from here to there and no new features until it's done (hint it never gets done).
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#45I would just add -- embrace the challenge. It actually sounds like a fun problem. After many years in tech, I've learned that I'd rather work on improving a pile of shit codebase that produces a lot of value than a pristine perfect codebase that does not.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#46A $20m/year is pretty impressive with that kind of spaghetti code/tech amalgamation. It would be certainly a fun project for your more junior developers to dig into it and understand the actively used features. That raises my next question: what exactly is wrong with your 3-people development team? Are you expecting only 3 of them to make major changes, let alone a full rewrite for such a project?
The way I see it is that you only have enough development resources to make minor changes or features that fit in the project's current spaghetti framework. Is that what management wants? If they want some big new features your only option is to find path of least resistance to implement them, especially if your budget is tight. Basically, add more hack-fixes and continue feeding the monstrous legacy. Unless you get more people, more budget you don't really have a choice of doing things "the proper way".
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#47First off, no, a full rewrite is not only not necessary, but probably the worst possible approach. Do a piece at a time. You will eventually have re-written all the code, but do not ever fall into the trap of a "full re-write". It doesn't work. But before you re-write once line of code - get some testing in place. Or, a lot of testing. If you have end-to-end tests that run through every feature that is currently used…
> It doesn't work. That's simply not true. I've inherited something just as bad as this. We did a full rewrite and it was quite successful and the company went on to triple the revenue. > get some testing in place Writing tests for something that is already not functional, will be a waste of time. How do you fix the things that the test prove are broken? It is better to spend the time figuring out what all the featur…
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#48Seeing a lot of people say that a rewrite is a terrible idea, but (as someone who doesn’t understand why) I’d love to hear a more fleshed out explanation re: why exactly that’d be a bad idea.
It can be difficult to fully replicate the existing system and there are frequently important but subtle reasons why the existing system has the architecture it does.
To the extent that one can make modular changes and address the most-important pain-points, one probably should.
Sometimes a complete rewrite is a better choice, but if embarking on that path, a fail-fast attempt at an MVP might be the right style to do so. If the MVP crushes the existing system in performance/benefits, then subsequent iterative development may yield a viable re-written replacement system.
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#49First off, no, a full rewrite is not only not necessary, but probably the worst possible approach. Do a piece at a time. You will eventually have re-written all the code, but do not ever fall into the trap of a "full re-write". It doesn't work. But before you re-write once line of code - get some testing in place. Or, a lot of testing. If you have end-to-end tests that run through every feature that is currently used…
> It doesn't work. That's simply not true. I've inherited something just as bad as this. We did a full rewrite and it was quite successful and the company went on to triple the revenue. > get some testing in place Writing tests for something that is already not functional, will be a waste of time. How do you fix the things that the test prove are broken? It is better to spend the time figuring out what all the featur…
Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?
#50First off, no, a full rewrite is not only not necessary, but probably the worst possible approach. Do a piece at a time. You will eventually have re-written all the code, but do not ever fall into the trap of a "full re-write". It doesn't work. But before you re-write once line of code - get some testing in place. Or, a lot of testing. If you have end-to-end tests that run through every feature that is currently used…
It's also a juggling job from hell so keep a cool head and seek support and resources for what needs to be done.
A big first step is to duplicate and isolate, as much as possible, a "working copy" of the production working code.
You now need to maintain the production version, as requests go on, while also carving out feasible chunks to "replace" with better modules.
Obviously you work against the copy, test, test again, and then slide in a replacement to the live production monolith .. with bated breath and a "in case of fubar" plan in the wings.
If it's any consolation, and no, no it isn't, this scenario is suprisingly common in thriving businesses.