"The people who’ve paid for us to write code (which I will call stakeholders for lack of a better term), do not want slop, even if they don’t even know what that means. They want The Feature, the Whole Feature, and Nothing But The Feature, but they don’t want it wrapped around a pile of shit. And you know it."

They also don't want to pay the true cost of the work nor wait for it to be done right. So they're gonna get slop sometimes.

I think a lot of engineers are trying really hard to produce value for their employers, and that this level of discourse seems to do so but really doesn't.

Your "stakeholders" really only care about their business making money. The truth is, they only care about technical debt/slop if it stops them from doing so.

I'd advise you to stop worrying about things that don't really matter (technical debt vs slop), and find ways to provide real value.

Very unconvincing. There are two issues at hand - "is sloppy code technical debt?" and "is sloppy code excusable?"

The headline implies it's going to take on the former but the article itself only addresses the latter.

Author very clearly says sloppy code is 'slop', not technical debt: Technical debt is not sloppily written code. It is clean code that is less than optimal.

If you're asking what we do with slop -- how do we categorize it in planning and do we fix as we go or do we call out a task to clean up -- that's a good question. He sort of touched on it with the Holmes-on-Homes parallel.

I think technical debt covers slop, Technical debt is debt you will eventually have to pay. Slope is just a "really bad" kind of debt that you would be better not getting into. Pragmatically, we get into debt because we have no choice. Be it lack of skills, lack of hands or lack of time, not because we "want" to get in debt.