First few months/years* (depending on the size of the project), learn the project with its idiosyncrasies, try to understand the business logic and reasons why things were done in the way they were done (often there are good reasons), write good code for your assignments, write tests to cover the existing behavior, even if it's buggy. Earn the trust of the team.
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.
All software will qualify as "poorly written" according to some criteria. We don't have an objective way to measure code quality. We have opinions, preferences, anecdotes.
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.
Yep you are 100% right. Developers who are not 100% focused on solving customer problems, in customer specified priority order, are in my opinion self-indulgent non-professionals.
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).
That’s why it’s kind
of painful sometimes if you have somebody else working on the
project. They never code stuff exactly the way you like to see it
coded. I remember when we were working on BASIC, I’d go back and
recode other people’s sections of code, without making any dramatic
improvement. That bothers people when you go in and do that, but
sometimes you just feel like you have to do it. -- Bill Gates, Programmers at Work (1986), ed. S. Lammers
As a Senior Engineer, dealing with “poorly written” code is just your job. Don’t get high and mighty about it. It’s likely covering edge cases you don’t know about too.
Read Working with Legacy Code and uses its techniques to add tests before making changes.
Does it work? If it works then you have to think twice before any changes. The irony is, poorly written often also means unintended consequences if once you refactor. Balloon grabs are the worst.
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.
30+ years of experience here, having worked on all kinds of very large scale VALUABLE legacy systems used to run airlines, airports etc. around the world:
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.
Not technically a senior, although I have filled that role before and have over 10 years experience.
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.
Poorly written is an opinion, not a problem that needs solving, so your team will not act on it. Carefully evaluate your definition of “poorly written”, enumerate the impacts as specifically as possible, and address each of them individually in priority order. Start with Does it work?
* 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
Each of the above options requires a different strategy to "deal" with it.
Depends. Is your company in the middle of a financial downturn and all it matters is that the software delivers the features that will keep your customers paying? Then probably you live with it and improve code as you go.
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.
A perfect software system is reliable, maintainable, performant, easily modifiable, and inexpensive.
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.
First few months/years* (depending on the size of the project), learn the project with its idiosyncrasies, try to understand the business logic and reasons why things were done in the way they were done (often there are good reasons), write good code for your assignments, write tests to cover the existing behavior, even if it's buggy. Earn the trust of the team.
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.
All software will qualify as "poorly written" according to some criteria. We don't have an objective way to measure code quality. We have opinions, preferences, anecdotes.
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.
Yep you are 100% right. Developers who are not 100% focused on solving customer problems, in customer specified priority order, are in my opinion self-indulgent non-professionals.
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.
staff/principal engineer opinion:
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).
That’s why it’s kind of painful sometimes if you have somebody else working on the project. They never code stuff exactly the way you like to see it coded. I remember when we were working on BASIC, I’d go back and recode other people’s sections of code, without making any dramatic improvement. That bothers people when you go in and do that, but sometimes you just feel like you have to do it. -- Bill Gates, Programmers at Work (1986), ed. S. Lammers
As a Senior Engineer, dealing with “poorly written” code is just your job. Don’t get high and mighty about it. It’s likely covering edge cases you don’t know about too.
Read Working with Legacy Code and uses its techniques to add tests before making changes.
Does it work? If it works then you have to think twice before any changes. The irony is, poorly written often also means unintended consequences if once you refactor. Balloon grabs are the worst.
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 cares about results
It's impossible to reason about, much less implement, fixes and features when the existing structure is special-case-ridden and incomprehensible.
30+ years of experience here, having worked on all kinds of very large scale VALUABLE legacy systems used to run airlines, airports etc. around the world:
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.
Not technically a senior, although I have filled that role before and have over 10 years experience.
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.
Poorly written is an opinion, not a problem that needs solving, so your team will not act on it. Carefully evaluate your definition of “poorly written”, enumerate the impacts as specifically as possible, and address each of them individually in priority order. Start with Does it work?
What does "poorly written software" mean exactly?
Each of the above options requires a different strategy to "deal" with it.Depends. Is your company in the middle of a financial downturn and all it matters is that the software delivers the features that will keep your customers paying? Then probably you live with it and improve code as you go.
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.
A perfect software system is reliable, maintainable, performant, easily modifiable, and inexpensive.
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.
"Poorly" (in quotes because it's a relative term) written codebases are the best:
- 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
easy in a few steps:
- 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
Rewrite it. Incur wrath of team. Get fired. Repeat with another lousy team.
refactoring?