All code and features are overhead. It requires maintenance when it breaks, or requirements change. It increases complexity when working on other parts of the system, as other new features have to ask "how does this interact with existing features?", even if the answer to that is "it doesn't". At Amazon one of the VPs had a rule of thumb that if a dev or team worked full-time on a new feature, they would be at 50% of their capacity after the feature was "done" for 3-12 months due to ongoing maintenance.
So yes, writing less code rather than more code for the same feature is good, generally. But all software requires some code, so the challenge is figuring out which code is necessary for which the maintenance and overhead costs are worth it.
Technical debt is a bit different; the code is there, but something about it makes it challenging to maintain. There's lots of reasons this can happen. Sometimes the business requirements change and the domain concepts or abstractions no longer make sense. Sometimes the technical requirements change and decisions made at the time are no longer the right ones, if they were ever right at all.
But the most common reason, in my experience, is that the people have changed. New people have come in, looked at existing systems and code, and either don't understand it or don't agree with how it was written from a personal stylistic point of view. Like a functional programming looking at a system that was designed with textbook OOP and calling that technical debt.
As you move into more senior technical positions or engineering management one of the bigger challenges is determining what's "real" technical debt that's worth tackling, versus what's perceived technical debt that's based on personal opinions.
All code and features are overhead. It requires maintenance when it breaks, or requirements change. It increases complexity when working on other parts of the system, as other new features have to ask "how does this interact with existing features?", even if the answer to that is "it doesn't". At Amazon one of the VPs had a rule of thumb that if a dev or team worked full-time on a new feature, they would be at 50% of their capacity after the feature was "done" for 3-12 months due to ongoing maintenance.
So yes, writing less code rather than more code for the same feature is good, generally. But all software requires some code, so the challenge is figuring out which code is necessary for which the maintenance and overhead costs are worth it.
Technical debt is a bit different; the code is there, but something about it makes it challenging to maintain. There's lots of reasons this can happen. Sometimes the business requirements change and the domain concepts or abstractions no longer make sense. Sometimes the technical requirements change and decisions made at the time are no longer the right ones, if they were ever right at all.
But the most common reason, in my experience, is that the people have changed. New people have come in, looked at existing systems and code, and either don't understand it or don't agree with how it was written from a personal stylistic point of view. Like a functional programming looking at a system that was designed with textbook OOP and calling that technical debt.
As you move into more senior technical positions or engineering management one of the bigger challenges is determining what's "real" technical debt that's worth tackling, versus what's perceived technical debt that's based on personal opinions.