Hacker News Board Hacker News, browsed like a classic message board
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

Post reply on HN
Print view View original

551–560 of 704 posts

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

#551

Post by jwatte »

pdimitar wrote: post #523
scarab92 wrote: post #428

Earlier quoted context omitted.

"Have everything in writing" is a bad mindset and is not going to save you. Exeutives are looking at you as the expert to deliver a good outcome. Which means making good decisions, managing expectations and keeping everyone in the loop. Generally, if it gets to the point of having to dig up who signed off on what, you've already failed. Often you won't even get the chance to dig up those emails, because delivering a…

> because delivering a bad outcome is enough for execs to write you off without even needing to hear your excuses. What makes you think they are excuses? Constantly chasing moving targets and not having even one of them agreed upon in writing is heaven for bad execs. I've seen it happen a good amount of times, my colleagues too. I don't view the "you changed requirements 20 times the last month and I can't keep up wi…

If the goal is to remove bad execs, then a document trail can help, although I'd suggest starting with some statistics like "over the last 3 months, we moved the goalpost 8 times, which led to an effective throughput of 4 weeks of work being done rather than the expected 12 weeks. How do you think we could improve these conditions?" Collaboration first.

Keeping email threads for reference is probably plenty data enough, btw; "signatures" sounds like the wrong approach. Maybe even just summarize the direction given in a wiki document with a change log with time stamps and requesting person, which you can review once in a while, and the sheer length of it might be enough to bring the point across.

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

#552

Post by bcrosby95 »

pdimitar wrote: post #528
bcrosby95 wrote: post #506

Earlier quoted context omitted.

> But this often fails because when Friday comes, something is on fire and management asks to please quickly squeeze this one thing in first. There's a solution to this problem: nothing goes live on Fridays. > and making the code touched by that change better. Getting buy-in from management on this always appeared to me as weird. The alternative is a codebase that can only ever get worse over time. So you either gott…

> Getting buy-in from management on this always appeared to me as weird. The alternative is a codebase that can only ever get worse over time. Well that's just the thing: they have no notion of a "bad code base". To them that's an excuse and a negotiation leverage by the programmer to ask for more money. They judge others by themselves I guess.

It just feels like an amateur hour thing.

If my plumber came to me to ask if he can just dry assemble the pipes and leave them that way I'm gonna get a new plumber.

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

#554

Post by latchkey »

sangnoir wrote: post #201
latchkey wrote: post #99

Earlier quoted context omitted.

You're assuming the existing flow is working perfectly and I agree with you that testing is a godsend. I constantly yell that testing is great. Heck, I even worked for Pivotal Labs that does TDD and pair development, and loved it. Let's say you start to write tests and start to see issues crop up. Now what? How do you fix those things? Github actions!? They don't even have source control to begin with. There are so m…

> Let's say you start to write tests and start to see issues crop up. Now what? How do you fix those things? I assumed the tests wouldn't be for correctness, but for compatibility. If issues crop up, you reproduce the issues exactly in the rewrite until you can prove no one depends on them (Chesterton's fence and all). The backwards-compatibility-at-all-costs approach makes sense if the product has downstream integra…

> 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 jquery on the same page as an example.

Writing tests for something like that is really a waste of time. Better to just figure out what's correct and rewrite correct code. Then write tests for that correct code... that's what moves things forward.

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

#556

Post by pdimitar »

bcrosby95 wrote: post #552
pdimitar wrote: post #528

Earlier quoted context omitted.

> Getting buy-in from management on this always appeared to me as weird. The alternative is a codebase that can only ever get worse over time. Well that's just the thing: they have no notion of a "bad code base". To them that's an excuse and a negotiation leverage by the programmer to ask for more money. They judge others by themselves I guess.

It just feels like an amateur hour thing. If my plumber came to me to ask if he can just dry assemble the pipes and leave them that way I'm gonna get a new plumber.

It's scary out there, man. A lot of people in HN judge by US companies and startups but I've only been in that bubble once for a few months and the rest of my 20 years of career has been everywhere else. And it's insanely bad in many places.

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

#557

Post by snapetom »

rendall wrote: post #375
fny wrote: post #64

> this code generates more than 20 million dollars a year of revenue From a business perspective, nothing is broken. In fact, they laid a golden goose. > team is 3 people, quite junior. One backend, one front, one iOS/android. Resistance to change is huge. My mistake, they didn't lay a golden goose--they built a money printer. The ROI here is insane. > productivity is abysmal which is understandable. The mess is just…

In my opinion OP should seriously consider this advice. I really mean nothing patronizing here, but I suspect OP does not have the corporate experience to handle this situation. This is a corporate equivalent of a double-black diamond downhill route. OP was hired by people who have little understanding of tech and already came in with guns blazing. I might almost wonder if OP's a sacrificial lamb. But, the tech advic…

> I suspect OP does not have the corporate experience to handle this situation.

I agree with this. OP doesn't say, but reading between the lines, corporate at best doesn't understand the ramifications, but corporate doesn't care about the ramifications.

They're getting 20 million in revenue from 3 cheap devs. Things are going great, according to corporate. They're not going to learn, and OP is going to get blamed when things can't get done.

I just quit because I was placed in a similar situation. The CEO, who does have a CS background albeit ancient, insisted there was nothing wrong with the tech stack that couldn't be solved by vertically scaling and then horizontally scaling. We were at the limits of the former and the architecture made many important parts impossible for the later, but that's another discussion.

The problem wasn't tech scaling, it was process scaling. We really couldn't divide work easily because there were often conflicts. People would join, see the horrible code, then leave. We specifically had to hire off-shore junior devs who didn't know any better and snowball them. I felt the last part was unethical and didn't want to be part of it any longer.

OP is not doing any favors for themselves, and especially not for the junior devs on the team. This job is going to set back the career for the junior devs. They're wasting their time on ancient methods and technologies.

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

#558

Post by snapetom »

ncmncm wrote: post #117
fny wrote: post #64

> this code generates more than 20 million dollars a year of revenue From a business perspective, nothing is broken. In fact, they laid a golden goose. > team is 3 people, quite junior. One backend, one front, one iOS/android. Resistance to change is huge. My mistake, they didn't lay a golden goose--they built a money printer. The ROI here is insane. > productivity is abysmal which is understandable. The mess is just…

$20M revenue is not the same as $20M profit.

Assuming profitability is even a problem, if $20M in revenue is coming from just 3 devs, the driving cost of the company isn't the tech. It's other parts of the company. That would be be another red flag against the leadership.

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

#559

Post by jspash »

samuellevy wrote: post #325
codingdave wrote: post #13

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…

Yeah, there's a process. It's something that I've done a bunch of times for a bunch of clients. There's so much low-hanging fruit there that's so easy to fix _right now_. No version control? Good news! `git init` is free! PHPCS/PHP-CS-fixer can normalise a lot, and is generally pretty safe (especially when you have git now). Yeah, it's overwhelming, but OP said that the software is already making millions - you don't…

Personally, I would never run a linter of any kind on a full codebase that doesn't have tests. After having been bitten by all kinds of bugs over the years, I wouldn't suggest auto-linting any file that you aren't actively working on.

It's rare that linting will actually make the code work better. Granted, it could catch some security bugs. But they can - and will - introduce new bugs. You just have to ask if it's worth the risk.

Post reply on HN