Think about it. Good code doesn't have many bugs, it's easy to maintain, extend, and improve, and it's easy to review manually to look for defects. Thus, modifying good code or interfacing with good code takes very little time and very few attempts to get right.
So where does our time get spent? Working with and using bad code of course. Bad code is hard to modify and extend, but almost all code needs modification in its life. Modifying bad code takes a lot of time and effort because it's crufty and broken so it tends to at best maintain or lower the overall code quality while adding features. Bad code spawns bad code. Poor APIs lead to clumsy workarounds and hacks in client code, which trickles down as technical debt elsewhere. Bad code tends to be awkward and difficult to follow so in order to ensure quality it needs to be tested thoroughly, which takes a lot of effort.
Technical debt has interest, and it's typically a pretty high rate. Pretty soon you find your development velocity is slowed because all your time is absorbed by dealing with bad code.
My advice: identify bad code and be ruthless about setting aside dedicated time to eradicate it. Have a policy or culture of constant refactoring when anyone makes a code change. Keep track of your major pain points and strive to solve them. Sometimes that's not possible if you are in a giant company but sometimes you can get a lot more done than you'd imagine. The best teams are the ones who spend their time writing more good code to go with existing good code, they tend to be exponentially more productive than teams who get bogged down in firefighting as a way of life.
Think about it. Good code doesn't have many bugs, it's easy to maintain, extend, and improve, and it's easy to review manually to look for defects. Thus, modifying good code or interfacing with good code takes very little time and very few attempts to get right.
So where does our time get spent? Working with and using bad code of course. Bad code is hard to modify and extend, but almost all code needs modification in its life. Modifying bad code takes a lot of time and effort because it's crufty and broken so it tends to at best maintain or lower the overall code quality while adding features. Bad code spawns bad code. Poor APIs lead to clumsy workarounds and hacks in client code, which trickles down as technical debt elsewhere. Bad code tends to be awkward and difficult to follow so in order to ensure quality it needs to be tested thoroughly, which takes a lot of effort.
Technical debt has interest, and it's typically a pretty high rate. Pretty soon you find your development velocity is slowed because all your time is absorbed by dealing with bad code.
My advice: identify bad code and be ruthless about setting aside dedicated time to eradicate it. Have a policy or culture of constant refactoring when anyone makes a code change. Keep track of your major pain points and strive to solve them. Sometimes that's not possible if you are in a giant company but sometimes you can get a lot more done than you'd imagine. The best teams are the ones who spend their time writing more good code to go with existing good code, they tend to be exponentially more productive than teams who get bogged down in firefighting as a way of life.