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

271–280 of 704 posts

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

#271

Post by jackblemming »

latchkey wrote: post #32
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…

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

Of course a full rewrite can be successful. This is the problem when people base their entire critical thinking on blog posts. They then go on to preach it everywhere as well!

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

#272

Post by wangii »

rgoulter wrote: post #161
wangii wrote: post #23

so, what's the problem of the code base business-wise?

"Business team have an aggressive road map" and "productivity is abysmally low".

there is no logical connection from "aggressive road map" to a messy code base. there are lots of ways to solve the problem of "productivity is absymally low", e.g. training, coding guidelines, given the team are all juniors. without an objective analysis, the problem you can see is always the phenomena, not the root. it appears to me more like an internal power struggle OP wants to win, than a real tech problem he/she wants to address.

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

#273

Post by larsnystrom »

First of all: PHP is fine. It really is.

Second: Doing a full rewrite with a junior team is not going to end well. They’ll just make other mistakes in the rewritten app, and then you’ll be back where your started.

You need to gradually introduce better engineering practices, while at the same time keeping the project up and running (i.e. meeting business needs). I’d start with introducing revision control (git), then some static testing (phpstan, eslint), then some CI to run the test automatically, then unit/integration tests (phpunit), etc. These things should be introduced one at a time and over a timespan of months probably.

I’d also have a sort of long term technical vision to strive against, like “we are going to move away from our home-written framework towards Laravel”, or “we are moving towards building the client with React Native”, or whatever you think is a good end outcome.

You also need to shield the team from upper management and let them just focus on the engineering stuff. This means you need to understand the business side, and advocate for your team and product in the rest of the organization.

You have a lot of work ahead of you. Be communicative and strive towards letting people and business grow. I can see you focus a lot on the technical aspects. Try to not let that consume too much of your attention, but try to shift towards business and people instead.

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

#274

Post by that_guy_iain »

> I know a full rewrite is necessary, but how to balance it?

A full rewrite of a functional 12-year old application? Yea, you're going to waste years and deliver something that is functionaly worse than what you have. It took 12-years to build it would realistically take years to rebuild. Fixing this will take years and honestly some serious skill.

What you want to do is build something in front of your mudball application. For the most part your application will be working. It's just a mudball.

Step 0. Make management and HQ understand the state of the application. To do this I would make a presentation explaining and showing best practices from various project docs and then show what you have. Without this step, everything else is pointless.

If they don't understand how bad it is. You will fail. Failure is the only option.

If the team is not willing to change and you're not able to force change then you're going to fail.

So once you have the ability to implement changes.

Step 1. Add version control.

Step 2. Add a deployment process to stop coding developing in production.

Step 3. Standardise the development env.

If you have views and not intermingled php & html:

Step 4. Start a new frontend and create endpoints that reuse the original code to return json for all the variables.

If not:

Step 4. Add views. Copy all the html into another file and then make a note of the variables. Step 5. Start a new frontend and create endpoints that reuse the original code to return json for all the variables.

... Carry on moving things over to the new frontend until everything is in the frontend.

Probably a year later.

Step 6. When adding new functionality you can either rewrite that section, do a decorator approach, or edit the original functionality.

That's without fixing the database mess or infra mess.

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

#275

Post by 41b696ef1113 »

29athrowaway wrote: post #49
latchkey wrote: post #32

Earlier quoted context omitted.

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

Exactly. If they write tests, they will be just doing TDD where the specification becomes a problem in itself.

It is a 12 year old legacy product. What specification exists other than, "Yesterday it did X when I clicked the button, but now it does not do that anymore."

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

#277

Post by Aeolun »

forty wrote: post #262
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, I agree, full rewrite from scratch are almost never the good approach. It will start a tunnel when you cannot add anything useful to production for months, and you will have no idea when you can finally ship the whole thing and when you do, it will be very risky. Do things progressively. Read the code, figure out the dependencies, find the leaves and starts with refactoring that. Do add tests before changing an…

In a team with only two people working on the monster it seems reasonable that they’d be able to manage two development streams at the same time.

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

#278

Post by psd1 »

Build a deployment server and a dev server. You can do this without the team knowing.

Do a swot analysis with the team. Make them answer why it takes days to do simple changes. Make them answer how they'd recover prod if the disks died.

Block access to prod. The team has to code on Dev and upload their artifact to cicd.

They'll hate the change but it's policy and it's enforced. What are they going to do?

Block artifact upload to deployment. They have to merge a branch instead. Be extremely available to help them learn the SCM tool.

They'll hate the change but policy, etc.

Set up a work tracker that lets you link bugs to features. Populate it with historic data. Triage it extensively. Show the team how each bug comes from an earlier change. Show the team git bisect. (You'll need a test server at this point.)

Set them a target: average time per feature or issue. You'll abolish this metric once it's attained for the first time. In the meantime, it's hard to game the metric, because the codebase is fucked.

Wait, and see if they come up with anything on their own - dinner is cooked when it starts making interesting thoughts.

If they fail to work it out, you'll need to coach them. Give them little breadcrumbs.

You want them to understand:

- slow delivery == poor business outcomes - bugs == poor business outcomes - git helps with bugs - cicd lets you write code - testing reduces (delivery time + bugfix time)

Only when the team understands this can they do the work of fixing the app. (IMO that's a total rewrite, but you're not short of advice ITT.)

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

#279

Post by krisoft »

latchkey wrote: post #32
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…

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

> How do you fix the things that the test prove are broken?

Uhm. The tests don’t do any such things.

> It is better to spend the time figuring out what all the features are, document them

Yes. And the tests you should write are executable documentation showing how things are. It is like taking a plaster cast of a fossil. You don’t go “i think this is how a brachiosaurus fibula should look like” and then try to force the bones into that shape. You mould the plaster cast (your tests) to the shape of the fossil (the code running in production). Then if during excavation (the rewrite) something changes or get jostled you will know immediately that it happened, because the cast (the tests) no longer fit.

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

#280

Post by Aeolun »

jtolmar wrote: post #127
seasoup wrote: post #102

A lovely knot to unravel! First, get everything in source control! Next, make it possible to spin service up locally, pointing at production DB. Then, get the db running locally. Then get another server and get cd to that server, including creating the db, schema, and sample data. Then add tests, run on pr, then code review, then auto deploy to new server. This should stop the bleeding… no more index-new_2021-test-jo…

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.

Post reply on HN