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

651–660 of 704 posts

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

#651

Post by password4321 »

password4321 wrote: post #214

As a prerequisite, get the code and database schema (+ scheduled updates to CSV's of number of rows/table, per-table storage size, per-database storage size, etc.) into source control ASAP. You can do this entirely on your own local machine day 1, automating rescanning and committing a diff at least daily. Also regularly commit all of the configuration files for the production environment (devops, installed packages/…

Log and review all server-side errors in PHP: https://www.cyberciti.biz/tips/php-howto-turn-on-error-log-f...

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

#652

Post by citrin_ru »

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…

> You can delete code as long as the tests pass.

It's true that poorly maintained code contains a lot of pieces which should be deleted but if tests where added post-hock it is hard to be sure that they cover all use cases.

After adding basic tests I would suggest to improve logging to get good understanding of how the software is used. Better to store them in a database which allows quick queries over all data you have (I'd personally would use ClickHouse but there are other options). But even with good logs you need to wait and collect enough data otherwise you can miss rare but important use cases. E. g. something which happens only during the tax season.

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

#653

Post by mkurzeja »

whattodochange wrote: post #67

Thank you for so many suggestions. The main issue is productivity within a context where the company is trying to reinvent itself in terms of marketing and business model. This has for consequence that many new big features are being requested and promised by management to headquarters. But in the last years, all bug evolutions have been failures. That's why I've been asked to intervene. I love the idea of the strang…

I had the chance to work with Strangler Pattern in multiple projects, and in general this is a good idea.

The thing I'd suggest taking a look at is the database. You really need to make sure the new part is not based on the old data model.

You can take a look at "getting started with DDD when surrounded by legacy systems" by Eric Evans - available for free and only 21 pages long. Our implementation of one of the suggested approaches failed in one project, but in retrospective, I think it was caused by the business not putting enough effort into the rewrite.

In general, on the high level it's very important to make the product vision, data model, processes clear and well thought. Without this, you will always get to a bad codebase within a couple of years.

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

#654

Post by kigiri »

beachy wrote: post #590
brigandish wrote: post #195

Earlier quoted context omitted.

Good point. Using stored procedures / views etc will help crystalise the API for the DB and allow work to happen behind that wall without breaking anything else in the meantime too. Once the work is done, bits of the wall can be replaced with better bits of wall i.e. improved sp's and views pointing to an improved schema.

Yep. views in RDBMS are much underrated, IMO just because they are old tech. It should be possible to use views to: 1) normalise the database (fold these ugly add-on tables as columns in the parent table, with suitable null constraints, then drop the add-on table). 2) Use views to add the add-on tables (now views) back in again. 3) Continue running the old application code against the views, which present the old, ug…

This use allow to update SELECT operations, but UPDATE / DELETE still have to be done on the old underlying schema right ?

No way to trigger a DELETE from a view right ? How would you approach this ?

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

#655

Post by maccard »

throwaway002ha wrote: post #149
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…

The biggest problem isn't even the codebase in this situation. When you keep finding bugs like that while refactoring and making things better, it will demoralise you. The productivity will stop when that happens. It also require above average engineers to fix the mess and own it for which there is not much benefit. Your refactoring broke things? Now it's your turn to fix it and also ship your deliverables which you…

> It also require above average engineers to fix the mess and own it for which there is not much benefit.

That's not true, it doesn't require above average engineers. It requires a tech lead that has the desire and backing to make a change, and engineers willing to listen and change. It doesn't require a 10x engineer to start using version control, or to tell their team to start using version control for example..

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

#656

Post by su-khi »

Go step by step. 1. Make buckets, identify standalone code (i.e. the one with no external interfaces including database read-writes) e.g. piece of code doing validations or some calculations. 2. Create a API for this with say AWS lambda functions or like. 3. Replace the old code/function with the API. 4. Take next function/piece of code and do it again. 5. In the next phase, involve functions having external interfaces such e.g. the one which is reading the databaes

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

#657

Post by andriytyurnikov »

First things first - treating code as an absolute asset is a mistake. Same outcome may be produced by different codebase. Second - present team goes away after rewrite - it is what it is - code is derivative of a vision and team. Freeze of development of legacy is strongly recommended during rewrite. Now - rewrite: You slash an app into segments on principle of cause-and-effect - input data produces output data, which serves as input for next segment. Then if you are risk minimizer - start with tail of cause-effect chain, and rewrite this shit. Continue segment by segment. After each segment reflect on need to refactor new codebase.

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

#659

Post by pacarvalho »

0. Use GIT.

1. Add a staging environment.

2. Add a CICD.

3. Add tests. Start by easy ones (new features) to get team used to writing them. Then important flows. If your team doesn’t have the bandwidth hire a contractor. Ex: https://avantsoft.com.br

4. Choose a part of the code the warrants being the first to refactor. Balance easiness with importance.

5. Define a better structure/architecture for it.

6. Refactor.

7. Repeat from 4 as many times as needed.

Also, consider micro-services on new features… may be an alternative to full rewrite.

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

#660

Post by chinathrow »

rendall wrote: post #648
rendall wrote: post #366

Earlier quoted context omitted.

I am inclined to agree. The other advice was excellent, but pointing local instances to production databases is a footgun.

I've kind of reconsidered this a bit. Right now, the only way to test that the database and frontend interact properly is to visit the website and enter data and see it reflected either in the database or in the frontend. It's less terrible to have a local instance that does the same thing. As long as the immediate next step is setting up and running a local database.

But the ting is, you have no idea if not even a single GET request fires of an internal batch job to do X on the DB.

I mean, there are plenty of systems in place who somehow do this (Wordpress cron I think) so that's not unheard of.

For me, still a nope: Do not run a against prod DB especially if the live system accounts for 20M yearly revenue.

Post reply on HN