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

621–630 of 704 posts

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

#621

People suggest rewriting little-by-little. Does that really work in practice? And why would one do it? Why not let that business rot-in-place so to speak, while building a new business on a new platform to "compete" with it? I worked for a company early in my career that sold a $1500 piece of software and had revenue of $15 million. When I was there, the head could was 70. Ten years later the head count is two - one…

Yes it works. You eventually get to a place that is “not too bad”, whilst still allowing new features to be developed and the business moving forward.

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

#622
post #152

Earlier quoted context omitted.

Rewriting little by little just means: each time you make a change, leave the source base at least a little better than you found it. Leave a few comments about the thing you reverse engineered. Delete a little dead code. Eventually you get the confidence to move from the lowest hanging fruit to deeper refactoring. You do it because that approach may be the best you can do with a rotten source base within your time a…

Honestly, that sounds like making bad code even worse.

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

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

#623
No full rewrites place.

I will start by properly correcting the NGINX codes.

I feel solving that will provide a bases to rewrite the other parts or the codebases.

Find new servers and backup everything onto the server and do the changes there including tests, and move successfully ones to production.

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

#624

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…

Your job is to deliver what the execs consider to be a good outcome.

That includes helping the stakeholders come up with a stable set of requirements. Most of the time when teams are dealing with a lot of requirements change, it's because they never captured the true requirements which usually change at a much slower rate.

Secondly, your job is also to manage expectations, so that execs know what the impact of any changes will be when they request them.

Changes aren't an excuse to deliver late or over budget. These parameters are flexible and new targets should have been agreed when the requirements change was requested.

Execs will usually assess your performance without discussion. There is no venue to bring your cache of documents to prove your innocence after the fact.

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

#625

Earlier quoted context omitted.

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

Your job is to deliver what the execs consider to be a good outcome. That includes helping the stakeholders come up with a stable set of requirements. Most of the time when teams are dealing with a lot of requirements change, it's because they never captured the true requirements which usually change at a much slower rate. Secondly, your job is also to manage expectations, so that execs know what the impact of any ch…

We all know the ideal theory. I am talking execs that constantly change requirements, refuse to sign under any stable requirements, and think everything is "quick and easy", and take offense when you try to manage their expectations.

Reasonable people I easily work with. It's the rest who are the problem.

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

#626
post #280

Earlier quoted context omitted.

This is the right way to think about it. My only disagreement is that I'd do the local DB before the local service. A bunch of local versions of the service pointing at the production DB sounds like a time bomb. And it's definitely worth emphasizing that having no framework, MVC, or templating library is not a real problem. Those things are nice if you're familiar with them, but if the team is familiar with 2003 vint…

> if the team is familiar with 2003 vintage PHP, you should meet them there. That's still a thing you can write a website in. You can write a website in it, but you cannot test it for shit.

There's no value to retroactive unit testing. Retroactive tests should be end-to-end or integration level, which you certainly can do without a framework.

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

#627
post #551

Earlier quoted context omitted.

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

Thank you -- good advice to put collaboration first. I sometimes have a problem that I assume the worst right away. But I've met some true villains in my life and career so maybe that's why. I'll do my best to implement your advice.

> and the sheer length of it might be enough to bring the point across.

This one sadly hasn't been true -- I tried it but I get blank stares and sometimes grumbling about making people read long stuff that I can just summarize to them. Maybe there's a way out of this conundrum as well.

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

#628
As others have said, you're in a precarious position: working with pure tech debt for a business that clearly has no interest in addressing tech debt.

First thing would be to use source control and get some sort of code review/release process in place.

Contrary to other suggestions of "then write tests for everything", I think that's bad advice. It's far more likely that you'll pigeonhole yourself and your team on complicated and unhelpful tests, particularly with dead code and trying to enumerate all the features that aren't documented. 3 things you could do in a short amount of time to radically increase the code quality:

- Lint all the code (php-cs-fixer is a good tool, rector can also help)

- At least start dependency management (with composer), even if it's empty.

- Introduce static analysis into the code review process (phpstan/psalm, in a CI preferably). Baseline suppression of existing errors are easy to generate.

Then personally I would try and aggressively purge dead code, which is easier said than done. Tombs (https://github.com/krakjoe/tombs) is a little awkward but can be helpful, especially if all there is is production. It requires PHP 7.1, I'm assuming you're below that, but the good news is that every route is in nginx; you can upgrade PHP piecemeal.

Again, handling tech debt sounds like it will be nigh impossible at this company, but modern PHP is really enjoyable and I hope you're able to experience it.

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

#629
You are thinking like an engineer and not a business person. A three person team that generates 20mm/yr is a huge success.

Your job isn't to fix the technical mess, but rather not kill the product. As an owner I wouldn't care how fast features can be released if my revenue started to drop.

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

#630
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…

Smells like executive stupidity to me.

There is some consensus that you can't fix stupid.

Even if you are very talented at repairing airplane engines in flight.

Post reply on HN