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

691–700 of 704 posts

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

#691

Earlier quoted context omitted.

I've done what I would consider as four rewrites that I can remember as large events in my life (although not fully what you'd expect). But all are good stories in my opinion. First one was the above example. It was for the largest hardcore porn company on the planet. Myself and my good friend Jeff rebuilt an already successful business IT department from the ground up and made it even more successful. Ever heard of…

Please tell me that you've retired now due to your incredible billing rates and track record of success.

Not everything has been a success. For example, unless you're stupid rich and can afford years of losses, never start/own a night club or you might end up working for the rest of your life to pay off your debts.

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

#692
post #398

The worst tech team you've ever seen and yet they are generating 20 million a year? I think you should give them the respect they deserve and understand the limitations they have been under. My thoughts: * Get the code in source control straight away * Get the infrastructure stable and up to date if it's not * Get CI pipelines set up. As part of this, make sure the code is running through a static analyser. This will…

> The worst tech team you've ever seen and yet they are generating 20 million a year? I think you should give them the respect they deserve and understand the limitations they have been under. If the right opportunity is there, you can make a lot of money on an awfully built product that barely keeps it together. That doesn’t mean that there aren’t a lot of risks involved with that and that things can’t go south in a…

There is definitely loads to fix and it does sound like the team was inexperienced but they were successful it seems.

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

#693
post #566

Earlier quoted context omitted.

>snowball them Could you define this phrase and what English dialect it's from?

> what English dialect it's from? I assume American English. Prior to the sexual slang made popular by the movie Clerks, snowballing in the context I used basically means to blindside or con someone. One definition on Urban Dictionary: "A situation where a criminal has found themselves in possession of an easy target and proceeds to rob them and leave them mortally wounded for fun, a synonym for getting iced." There'…

In my dialect, which is some sort of American English, trying to snow someone means trying to BS or con them.

Blindsiding someone means taking them unawares - hitting them when they aren't looking, physically or metaphorically.

A speedball has cocaine in it, which is sometimes known as snow.

"Iced" can mean killed, but the Urban Dictionary definition is oddly specific

I agree about "snowballing" meaning increasing in size or momentum, but it doesn't have to refer to a problem.

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

#694
post #501

Earlier quoted context omitted.

You're making a silent assumption that the original team is well informed about why the things are like they are and that they know what they are doing. I think it is not always the case. I've been to a project once where the mess in the original system was the result of the original team not knowing what they were doing and just doing permutation based programming - applying random changes until it kinda worked. The…

The original team may not have been the best at the task, but they still managed to deliver 100 MM in revenue. Sometimes the things they leave behind/ignore simply don’t matter to the business/useful tech. Particular to ad tech, the lifespan of any particular software is lower than you’d expect (unless your google/Facebook). Technology that pays out big one year will become pretty meh within 3 years. In the case abov…

Revenue is a crazy kpi for technical excellence. You should never let a high revenue rely on extremely bad code.

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

#695
Don't do anything without buy in from mgmt. I'd come up with some sort of plan, give it 6 months and be prepared to bail if there is no action on your plan.

I was brought on board to 'modernize' a similar application. Almost a year later we haven't modernized anything... Despite a lot of promises from mgmt up front they have now gone into the 'if it's not broke don't fix it' mode.

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

#697
As others, I would not recommend a full rewrite.

But first, I'd take apart some assumtptions:

- this code generates more than 20 million dollars a year of revenue

This is GOOD! Thsi means this project is important. There WILL be budget for this.

You need to find out two things:

1. What is the PROFIT margin? 2. HOW does this generate revenue?

If you can increase profits (or promise to) by either making it easier to generate more revenue (onboarding woes of new customers / sales UI, etc) or a bigger margin, you'll be golden.

- it runs on PHP

This is not necessarily bad, check ylour code wars at the entrance.

- it has been developed for 12 years directly on production with no source control ( hello index-new_2021-test-john_v2.php )

THIS is one of the things that need to be remedied - source control NOW. Get a professional course on git for all devs, add some nice dinner for teambuilding.

- it doesn't use composer or any dependency management. It's all require_once.

This needs to be adressed.

- it doesn't use any framework

This needs to be adressed.

- the routing is managed exclusively as rewrites in NGInX ( the NGInX config is around 10,000 lines )

This needs to be adressed!!!!!!!

- no code has ever been deleted. Things are just added . I gather the reason for that is because it was developed on production directly and deleting things is too risky.

Source control should take care of some. The rest is on you sitting with the product manager to find out WHAT is the core, what needs to be removed, what features need to be kept.

(bunch of horrible code smells that ALL need to be adressed.)

- team is 3 people, quite junior. One backend, one front, one iOS/android. Resistance to change is huge.

OK... if the team is junior, you need to lead.

And WTF is an iOS / Android developer doing in your team?

- productivity is abysmal which is understandable. The mess is just too huge to be able to build anything.

This business unit has a pretty aggressive roadmap as management and HQ has no real understanding of these blockers.

YOu need to sit with business and make them understand the blockers, the challenges, the timelines, AND the opportunities that your solutins will bring.

And post COVID, budget is really tight.

No it is not. See above.

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

#698
I have experience in similar situation, not sure we are talking about the same project.

I suggested full rewrite and got fired in 3 weeks (actually it was a subcontractor role). I have been considering myself as be really good at presentations and persuading executive people to understand what I am doing and what I will be doing, but the situation was too much for me to take on. They didn't like this unrealistic 3-months roadmap to rewrite the whole thing, which does nothing on their point of view but still needs paying the whole team (even though I was the only one). So I told them we are gradually improving it, and did this full-rewrite underground on my own. It consumed me ~13 hours every day, but I was happy myself and was enjoying the birth of the product. Finally after 10 weeks, I gave up to myself and their frustration.

Regarding your problem, I totally suggest dumping your codebase into a git repo first of all, add some cypress/playwright testing to carefully probe the major functionalities, build ci for these, and start gradually removing old version files. After then, just forget how messy it was, what you thought in the first place, consider this beast as a perfect engineering gift (like linux kernel), then start making small changes then adapt yourself into it. Guide the team to follow your methodologies to treat the code, and tell the executive team that the legacy codebase looks great but complex enough to move quickly as it was a brand new startup project.

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

#699
Better look at it from a career perspective. Is there any visibility for upper management of refactoring/rewriting this mess? For them it might look like a bunch of months without any new features. Think short-term. Your goal shouldn't be to maintain that code for a long time. Add some fancy features and present it to management. Get a promotion and switch companies.

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

#700

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…

“Never rewrite” is a popular cargo-cult that sprang from a well known blog article that made the rounds some years ago. The urge to rewrite can be a naive impulse for sure, but there are LOTS of cases where new and better technology can result in tremendous gains, or where a code base is simply too far gone to redeem. The biggest successes of my career have almost all been ground up rewrites of existing products using new technology or techniques that resulted in orders-of-magnitude improvements in performance and ROI. If you can make incremental improvements that’s great, but sometimes it’s just not possible to rewrite “a piece at a time” because there are no pieces, just one big ball of mud. To the original author: If you don’t rewrite this mess, your competitors will. I’d say: lay out the case for an overhaul, stand your ground, don’t implement any new features until you’ve got a clear path to reducing technical debt, and if you can’t get buy-in to an overhaul just leave. What you’re describing sounds like a textbook scenario for burnout and there are lots of other opportunities where you can work on things in ways that you’ll actually enjoy.
Post reply on HN