3 ms·

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 enou

by 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.

by kpil 10y ago

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.