Start to identify well-defined areas with a good ratio of impact/risk/difficulty and propose changes to tackle them. Refactor/redesign such solution gradually, with feature toggles. Rinse and repeat.
*"First few months/years" may seem exaggerated. The point is that you should be tackling the problems only if you really understand them, and that's unlikely the case when you just come into the project. As you learn, you understand smaller pieces and can tackle those. But to tackle the big problems, you often need to understand much more of the project.
I focus more on "does it work," meaning does it meet requirements and deliver value? I also look at fragility and security problems. Software may look well-written but not work. It may look "poorly-written" but work reliably.
I do mostly maintenance work as a freelancer. I can't afford to waste my time worrying about why some code looks like it does, because my customers don't care about that. I don't spend a lot of time changing code to make it conform to my opinions about what "good code" should look like.
Realise that it is not really your employer who pays your salary. Your salary is ultimately paid for by customers. All your employer does is to redirect some of the customer money to you. If the customers stop paying, no salary for you.
figure out business priority. if something in poor state.. it impacts you personally, you team, organization, overall business?
the higher it blast radius, speak with you staff or principal engineer and raise the issue. sometime tech debt accumulate over time while no one watching. at some point the debt must be paid or innovation will halt.
think closely about what makes it “poor” and what impact this has. i wrote most elegant code (me opinion) that never ship to production.
also worked on old..dusty messy code that go against design approaches. but it ship to 20 million customer and contribute hundred of million USD in revenue. so to say “poor” maybe meaningless at time because it actually make money vs me code that gave negative contribution ($0 earning plus cost of me and my teams time).
Read Working with Legacy Code and uses its techniques to add tests before making changes.
The business doesn't care about "aesthetics". It cares about results. I'm certainly not going to defend poorly written software, only that it all depends on your POV. So unless un-poorly can deliver significant value to the business it's best to consider other ways to deliver value.
https://github.com/97-things/97-things-every-programmer-shou...
It's impossible to reason about, much less implement, fixes and features when the existing structure is special-case-ridden and incomprehensible.
1. Always prioritise work based on customer priorities. Not your personal subjective preferences. So keep a list of To Do’s in customer selected priority order.
2. Always and only work on the #1 customer priority. If the code to solve #1 priority needs refactoring then FIRST write system level tests that specify exactly what the code should do. And then refactor, followed by adding the new feature.
3. Goto 1.
It’s simple. It works.
I generally leave for a different team. There's never been any appetite to tackle significant technical debt due to the constant push for more deliveries.
If it's a small part of the team's work, then possibly working to improve it or just learn to live with it. Stuff like automation scripts can help if it's something repetitive. Almost nothing has helped with code quality though. A lot of that has to due with the lack of time to do in depth code reviews, having a tight schedule to meet so you shoehorn the feature in with minimal refactoring, etc. I hate it, but that's the way it is.
* It doesn't work (i.e. lacks critical features)
* It works, but with errors (has bugs)
* It works, but is slow/inefficient/unoptimised
* It works, but the code is difficult to understand
* It works, but it's difficult to expand/modify
* Several, or all, of the above
Is your company riding a wave, doing great with hiring, and the software is measurably bad enough that it affects revenue / engineering productivity? Then you can make the case for rewriting it.
No software system is perfect.
A good software system is some combination of those things that is satisfying the business objectives and needs. A bad software system has clear shortcomings that are making it difficult to meet business needs.
A poorly architected system, which includes poor quality code, can start out as a great software system and by its own poor design decisions, become bad over time due to the gradual accumulation of tech debt. So when we construct software systems, we cannot just build for the immediate business need. It's our job to ensure our system is adaptable enough to meet future business needs. Business requirements change. We cannot, as professionals, sneer this off because our software was never built for that. It will never be perfect, but nothing stays the same forever.
When it comes to handling poor software, think evolution, not revolution. You cannot rebuild a mature software system without spending lots of time and money, and there will always be problems every step of the way. In the poorest quality software systems I've worked with, it's usually a lack of automated testing and a lack of any established convention, so I'll focus on those. Lacking these leads to a hedge maze of dependancies and a whack a mole situation where fixing one bug creates more. This makes feature development a slow and expensive process, and deployments a risky endeavor. Start by refactoring one unit at a time, as part of feature development. Incorporate good code and process conventions as hardline requirements in the CI/CD pipeline (or building CI/CD pipeline, if none exist). Proper unit testing helps build confidence in the code base and enforce dependency separation. As various components are refactored, the quality should measurably improve. Measurable is key, both internally and also for your stakeholders.
But those may not be the only issues or even an issue at all. There could be performance issues, deployment issues, reliability issues, etc. Perhaps the code base is too overengineered. Perhaps the external dependancies are unreliable. Perhaps a critical component of the system no one understands is not meeting performance expectations. Perhaps management is simply asking too much out of too small of a team. It's hard to give advice on specifics when the problems of poor software can be so broad. I focused on lack of tests and spaghetti dependancies because these issues are universal to poor software.
- tons of opportunities to improve things!
- fixing bugs is like being Sherlock Holmes. I enjoy that
- and the best is: if you need to deliver something that has a deadline and you couldn't make it, you can always blame the "poorly" written codebase
- start off by thinking you know everything better than anyone else
- kick off a rewrite, introduce a lot of bugs and unhanded corner cases that were previously covered by "ugly code"
- leave the work half done and get reassigned or better yet promoted because you "clearly" know what you are talking about