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.
Comments
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.