4 ms·

I don't think it is at all useful in technical discussions as it anchors the discussion in backwards reasoning (deduction). Better to start with real observati

I don't think it is at all useful in technical discussions as it anchors the discussion in backwards reasoning (deduction). Better to start with real observations about the workings of a particular piece of software or architecture, then reason about why it may have certain 'bad' properties. This more often leads to action and mutual understanding, but requires actually putting in some mental effort. In your example, calling some code 'ugly' is another example of what I'm saying not to do, it is starting at a conclusion and reasoning backwards. For an example of what I'm advocating, say you started a project and defined certain architectural principles after a series of discussions with stakeholders. Let's say one of those principles is efficiency/speed of execution because the stakeholders use the software synchronously. So, that is how you define code quality in that project. You benchmark and eliminate hotspots until you reach acceptable performance. Independent of context, fast code may appear ugly to some people, but in this context it is not, perhaps it is even beautiful as it so embodies and elevates the architectural principle it was designed around. Developers now have a frame to surface issues and everyone can agree on what an issue is, because you defined what an issue looks like and why it is important, up front, as one of your architectural principles. This is basically a context-bound value system. There is no need to even use the words 'technical debt'. In a real project you have multiple competing architectural principles but these are prioritized so you know how to evaluate whether or not something is 'good' or 'bad'. As a project leader I believe it is your job to define these architectural principles, to enable developers to frame 'good and bad' as well as to prioritize their work. I used this approach when leading a project and it was very effective.

Retric 5y ago
If your code isn’t fast enough to meet spec, that’s just a defect. QA should create a ticket even if you don’t. There are however a meaningful class of issues that have zero direct impact outside the team, but are still issues for your team. The best example of that is how long it takes to setup your build environment, frankly your users have zero reason to care but it can still slow your teams progress over time. Really the cost and payoff of fixing it is simply time / a better work environment. Different teams will of course use technical debt to describe stuff outside of that context, but if it directly benefits users then it’s really something else.

Retric 5y ago

If your code isn’t fast enough to meet spec, that’s just a defect. QA should create a ticket even if you don’t. There are however a meaningful class of issues that have zero direct impact outside the team, but are still issues for your team. The best example of that is how long it takes to setup your build environment, frankly your users have zero reason to care but it can still slow your teams progress over time. Really the cost and payoff of fixing it is simply time / a better work environment. Different teams will of course use technical debt to describe stuff outside of that context, but if it directly benefits users then it’s really something else.