"Non-tech managers, sadly, do not understand what the TD is..."
That's been my experience as well. I've heard them call bugs TD. But bugs are not TD, in general. Some might be, when the TD bleeds through.
Bugs are customer facing issues, and make the customer unhappy. TD is developer facing issues, and make the developer unhappy.
Sometime TD is caused by external factors. Like "OpenGL is out, Metal is in", or "Win32 is yesteryear, now move to WinRT (followed by, oops, just kidding)," or "those APIs that we deprecated 15 years ago? They're gone now. What do you mean we didn't give you enough warning?" or "68000, no no, PowerPC, no no, Intel, no no, ARM".
These kinds of externally imposed TD are part of the table stakes to stay in the game. Fortunately, they are the kind of TD that non-tech managers can understand.
The internal TD is the dirty kitchen. And who is to blame? The product managers? The project managers? The program managers? The product owners? The engineering managers? No, no, no, no, and no. The blame on TD is squarely on the shoulders of the developers. (My shoulders.)
It'd be nice to place the blame on someone else, but at the end of the day the managers are not the one's who made the mess... made the TD... the developers made the TD.
And the developers are the ones who have to clean up the TD, or suffer the ongoing pain of having TD.
Insightful comment, but I have to disagree in the end.
In a perfect world, managers let developers take as much time as they need to do their job properly. In this perfect situation, then indeed TD is the developer's fault.
But that haven't been my experience of the industry, nor the one of most devs I've been talking to. At least in the ecosystem I know well (startups and smallish tech companies), there is tremendous pressure to "shit as many features as possible" fast and furiously (half of them will never even be used.)
I'm not sure if that was a typo for "ship", or intentional... either way, I concur. And the wording as is is funnier.
The push back on the tremendous pressure has to come from the developers. Carving out some time to address the TD has to be driven by the developers. Identifying the TD has to be driven by the developers. Prioritizing the work to address the TD has to be championed by the developers.
Management will blissfully de-prioritize TD work over feature work or bug fixing work. Every time. Developers are responsible to make sure TD gets addressed, at the right time, with an appropriate priority.
Most professional developers I've worked with are good about keeping the code base clean as they go — working clean — when they can. The "Kaizen 5S" of software development. Or the mise en place of software development, to extend the kitchen analogy.
"Non-tech managers, sadly, do not understand what the TD is..."
That's been my experience as well. I've heard them call bugs TD. But bugs are not TD, in general. Some might be, when the TD bleeds through.
Bugs are customer facing issues, and make the customer unhappy. TD is developer facing issues, and make the developer unhappy.
Sometime TD is caused by external factors. Like "OpenGL is out, Metal is in", or "Win32 is yesteryear, now move to WinRT (followed by, oops, just kidding)," or "those APIs that we deprecated 15 years ago? They're gone now. What do you mean we didn't give you enough warning?" or "68000, no no, PowerPC, no no, Intel, no no, ARM".
These kinds of externally imposed TD are part of the table stakes to stay in the game. Fortunately, they are the kind of TD that non-tech managers can understand.
The internal TD is the dirty kitchen. And who is to blame? The product managers? The project managers? The program managers? The product owners? The engineering managers? No, no, no, no, and no. The blame on TD is squarely on the shoulders of the developers. (My shoulders.)
It'd be nice to place the blame on someone else, but at the end of the day the managers are not the one's who made the mess... made the TD... the developers made the TD.
And the developers are the ones who have to clean up the TD, or suffer the ongoing pain of having TD.
Insightful comment, but I have to disagree in the end.
In a perfect world, managers let developers take as much time as they need to do their job properly. In this perfect situation, then indeed TD is the developer's fault.
But that haven't been my experience of the industry, nor the one of most devs I've been talking to. At least in the ecosystem I know well (startups and smallish tech companies), there is tremendous pressure to "shit as many features as possible" fast and furiously (half of them will never even be used.)
I'm not sure if that was a typo for "ship", or intentional... either way, I concur. And the wording as is is funnier.
The push back on the tremendous pressure has to come from the developers. Carving out some time to address the TD has to be driven by the developers. Identifying the TD has to be driven by the developers. Prioritizing the work to address the TD has to be championed by the developers.
Management will blissfully de-prioritize TD work over feature work or bug fixing work. Every time. Developers are responsible to make sure TD gets addressed, at the right time, with an appropriate priority.
Most professional developers I've worked with are good about keeping the code base clean as they go — working clean — when they can. The "Kaizen 5S" of software development. Or the mise en place of software development, to extend the kitchen analogy.
(I admit, I am a Clean Code evangelist.)