4 ms·

> technical debt is part of our KPIs. If it's not captured, it's not actionable This is where I suspect manager-types and developers have a vigorous divergence

> technical debt is part of our KPIs. If it's not captured, it's not actionable This is where I suspect manager-types and developers have a vigorous divergence in values. Professionals routinely encounter situations where something is wrong and needs to be "actioned" but its wrongness isn't effectively measured by any metric (other than the opinions of the experienced people looking at it). There is a certain species of manager who has taken Taylorism a bit too far and says that anything not reflected in the KPIs is not real and not getting acted upon. I hope this isn't what you're expressing here, but oh man is that mindset frustrating.

kpil 10y ago
On the other hand, at the end of the road - or the rewrite - something should have been gained in terms of money, risk or time. Being shitty is not reason enough, but it's almost always possible to reason and quantify and weigh the cost versus the benefits.
- superuser2 10y ago
  Of course something should be gained, but that doesn't mean you can always tell how much would be or was. There is no mature "actuarial science" of software development. The market can provide concrete pricing for new feature development; engineers can't tell you how many dollars of tech debt you're in or give three significant digits on the probability of a major outage tomorrow. That doesn't make money/risk/time costs which are difficult to measure any less real and it doesn't make them smaller than the ones which are easy KPIs. Nor can you necessarily look at the movement of measurable KPIs and say "man, that rewrite was a waste of money." Who's to say things wouldn't have been worse without it?
- dekimir 10y ago
  > it's almost always possible to reason and quantify and weigh the cost versus the benefits I don't think so. As a pretty good analogy, can you quantify the benefit of replacing knob-and-tube wiring in an old house? Now consider that the house across the street keeps its old wiring for the next twenty years without anything bad happening.
- timv 10y ago
  Senior staff in pretty much all organisations are given some latitude with respect to performing tasks that they believe will be beneficial without needing to produce a specified cost-benefit. We have one-on-one catch-ups with staff, we have all-hands meetings, we visit clients, read books and articles, attend industry functions, issue press releases, meet with potential investors, etc. There's value in all those things, but very rarely do we need to account for the fact that we spend time on them. Senior engineering staff need that same freedom - it should be totally appropriate for them to make that call that "I'm accountable for the technical quality of this code, and I've decided that this needs to be done". That requires some sense of business acumen - there needs to be an appropriate balance of technical investment to business investment - but that's part of the role of being a senior dev / tech lead / architect / whatever-your-organisation-calls-them.
  - kpil 10y ago
    I agree. I am not saying that you always need a detailed balance sheet, just that it's good to reason about the benefits. It's especially hard to quantify risks - that's where you really need the expertise. What I wanted to point out is that there seems to be quite many developers that actually do not have a sense of business acumen, and are willing to spend alot of money on low priority tasks, just for their own personal pleasure.

kpil 10y ago

On the other hand, at the end of the road - or the rewrite - something should have been gained in terms of money, risk or time. Being shitty is not reason enough, but it's almost always possible to reason and quantify and weigh the cost versus the benefits.

superuser2 10y ago
Of course something should be gained, but that doesn't mean you can always tell how much would be or was. There is no mature "actuarial science" of software development. The market can provide concrete pricing for new feature development; engineers can't tell you how many dollars of tech debt you're in or give three significant digits on the probability of a major outage tomorrow. That doesn't make money/risk/time costs which are difficult to measure any less real and it doesn't make them smaller than the ones which are easy KPIs. Nor can you necessarily look at the movement of measurable KPIs and say "man, that rewrite was a waste of money." Who's to say things wouldn't have been worse without it?
dekimir 10y ago
> it's almost always possible to reason and quantify and weigh the cost versus the benefits I don't think so. As a pretty good analogy, can you quantify the benefit of replacing knob-and-tube wiring in an old house? Now consider that the house across the street keeps its old wiring for the next twenty years without anything bad happening.
timv 10y ago
Senior staff in pretty much all organisations are given some latitude with respect to performing tasks that they believe will be beneficial without needing to produce a specified cost-benefit. We have one-on-one catch-ups with staff, we have all-hands meetings, we visit clients, read books and articles, attend industry functions, issue press releases, meet with potential investors, etc. There's value in all those things, but very rarely do we need to account for the fact that we spend time on them. Senior engineering staff need that same freedom - it should be totally appropriate for them to make that call that "I'm accountable for the technical quality of this code, and I've decided that this needs to be done". That requires some sense of business acumen - there needs to be an appropriate balance of technical investment to business investment - but that's part of the role of being a senior dev / tech lead / architect / whatever-your-organisation-calls-them.
- kpil 10y ago
  I agree. I am not saying that you always need a detailed balance sheet, just that it's good to reason about the benefits. It's especially hard to quantify risks - that's where you really need the expertise. What I wanted to point out is that there seems to be quite many developers that actually do not have a sense of business acumen, and are willing to spend alot of money on low priority tasks, just for their own personal pleasure.