Why would you not want business people to understand the technical constraints? Maybe easier in the short term to make the decision for them but longer term that just builds up barriers and an “us” and “them” culture, which becomes very unhealthy.
Oh, they should understand technical constraints on an appropriate level! I just think that technical debt should not be part of that, just as a lawyer spares you most of the constraints they experience.
I like your second sentence though! If explaining technical debt helps with the "us" culture, it should be done.
It's just that, from my experience, it usually does the opposite. And I mentioned the reasons: it is too difficult to explain and to understand, even for developers. Also, the most important aspects/impacts will almost never be measured - not talking about development speed here (which is already too difficult to measure), but motivation, attrition, broken window behavior and so on.
A better way to create an "us" culture as a developer is to make sure to be involved into product decisions from the very beginning, including contributing ideas. And being hold to the except same KPIs/OKRs as other departments. That also means, as a developer you need to have the discipline to heavily sacrifice code quality and create technical debt sometimes and you might have to push this against other developers. That is the price to pay.
valenterry|5 years ago
I like your second sentence though! If explaining technical debt helps with the "us" culture, it should be done.
It's just that, from my experience, it usually does the opposite. And I mentioned the reasons: it is too difficult to explain and to understand, even for developers. Also, the most important aspects/impacts will almost never be measured - not talking about development speed here (which is already too difficult to measure), but motivation, attrition, broken window behavior and so on.
A better way to create an "us" culture as a developer is to make sure to be involved into product decisions from the very beginning, including contributing ideas. And being hold to the except same KPIs/OKRs as other departments. That also means, as a developer you need to have the discipline to heavily sacrifice code quality and create technical debt sometimes and you might have to push this against other developers. That is the price to pay.