Live data from Hacker News

Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?

news.ycombinator.com

631–640 of 704 posts

Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?

#632
post #610

Earlier quoted context omitted.

> The shitty software probably isn't the product The shitty software is what sells the product, from the description. Even if the shitty software is a sales/inventory management tool or 'whatever', from the description it is obvious that it is vital to whatever business they are doing. It doesn't matter whether it was built with Microsoft Access and Excel files. If its contributing a major part of that $20m /year, it…

Well, I don't agree. You'd struggle to do it without any software at all these days, but you can certainly do it without anything written in-house. My point about Access (or Excel or whatever as you say) was that that would be the very early days of something starting to happen in-house, that wouldn't even be the hypothetical 'script kiddies'.

> but you can certainly do it without anything written in-house

Nope. Not really. Your average SV startup idea in which the end users will do some simple, but catchy things with your app - yeah, go all no-code if you want to get it started.

But, in real business, in which there are inventories, sales, vendors, shipping companies, deliveries, contracts, quotas, FIFO and LIFO queues and all kinds of weird stuff, things don't work that way. You may end up having to code something specific in order to be able to work with just one vendor or a big customer even. They may even be using Excel. You do it without blinking because millions of dollars of ongoing revenue depend on such stuff.

Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?

#633

First 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.

I think you are being needlessly pedantic. Everyone understands that "full rewrite" means "restarting from scratch" in this context, especially since the poster was very clear that eventually everything will be touched.

Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?

#634

Earlier quoted context omitted.

Honestly, that sounds like making bad code even worse.

Apart from the fact they said making the code better each time?

LOL. Did you read the OP? Code is in PHP.

Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?

#635
I've been in a situation like this before. Lots of good advice here. I ran eng for a product that supported an entire company for a while, and the company was eventually acquired. I don't want to repeat stuff from all the comments so feel free to reach out (my contact info is in my profile) if you want some 1:1.

tl;dr - Don't rewrite, focus on the biggest pain points first and work your way down. Build a framework in which the junior devs can work on new stuff while you untangle the big ball of spaghetti - they'll think they're doing the big fun stuff and feel like they've won, while you'll be able to be heads-down making things better in the long run. If there's any analytics, you can use that to justify some big changes if you can show that inefficiencies (like poor DB performance and cache usage) affect revenue.

Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?

#637

Earlier quoted context omitted.

> I assumed the tests wouldn't be for correctness, but for compatibility. You're assuming that the people coming in to write these tests can even make that distinction. How do you even know what the compatibility should be without really diving deep into the code itself? Given how screwed up the codebase already is, it could be multiple layers of things work against each other. OP mentioned multiple versions of jquer…

> How do you even know what the compatibility should be without really diving deep into the code itself? You can pretty much black-box the code and only deep dive when there are differences. Here's what I've done in the past for a rewrite of an over-the-network service: 1. Grab happy-path results from prod (wireshark pcap, HTTP Archive, etc), write end-to-end tests based on these to enable development-time tests that…

All of that, while technically correct and possible, is vastly more complicated and time intensive than a rewrite of what the OPs description of the codebase is.

Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?

#638

Earlier quoted context omitted.

Source control seems like a straightforward first step, regardless of what approach is going to be taken going forward

One would think, but how do you go from source control to deployment on the production server though? If they were editing files on the server directly, there could be a whole mess of symlinks and whatever else on there. Even worse, how do you even test things to see if you break anything? It is a can of worms.

They can literally copy the whole directory from their local machine to production as a first step for all I care.

How do they test things on production? If there’s a bug how do they revert to the previous version? There are way more issues without source control than with.

Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?

#639

Earlier quoted context omitted.

My first instinct was "get some testing in place" too. That served me well in recent projects where I was in a similar situation. I was wondering if anyone has any advice on how to make sure your tests are... comprehensive? I was fortunate enough to have full flow tests in place from the beginning and a great team which knew the intricacies of the subject matter. We made lists of usecases and then tried to find ortho…

One more thing I’d add; for the love of all that is holy make sure the tests run lightning quick. What you want to do is first reduce the cost and risk of making changes, to a close to zero as possible. Then, come up with a broad system design that defines higher levels of abstraction. Your goal is not to redesign the system from scratch but to specify the existing hierarchies which are currently implicit in the code…

> The way to change a culture is to set such a strong positive example that people naturally went to follow. Telling other people their work sucks is not that example, but first pitching in to speed up development cycles can make everyone happy.

This is the part I'm having the most trouble with. What if you are at a place which is not software minded? Any tips on making them understand?

Re: Ask HN: Inherited the worst code and tech team I have ever seen. How to fix it?

#640

First 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…

All good points, but…

This is a clear case where he needs to look for another job IMMEDIATELY.

Here’s why…

1. The problems listed are too technical and almost impossible to communicate to a non-technical audience meaning business or c-suite.

2. The fixes will not result (any time soon) in a change that’s meaningful to business like increased revenue or speed to market. Business will not reward you if you are successful or provide resources to get the job done unless the value is apparent to them (See #1).

Employment is a game. Winning that game means knowing when to get out and when to stay.

It’s time to plan your exit both for your own sanity and the good of your family.

Post reply on HN