5 ms·

The article has some good points but I think the primary issue is that of economics, most organizations are too small for the cultural aspect to override econom

by omeid2 7y ago

The article has some good points but I think the primary issue is that of economics, most organizations are too small for the cultural aspect to override economic concerns. Maintenance doesn't provide immediate economic value, not to customers, not to board meetings, not to developers, not to managers promotions. Developers like myself like it or not, maintenance is a strategic investment driven by long term policy for which many organization have none or can't afford one. Joel Splosky once said "I can’t tell you how many times I’ve been frustrated by programmers with crazy ideas that make sense in code but don’t make sense in capitalism". I think it applies to cost of maintenance fairly reasonably.

ravenstine 7y ago
By the time that outstanding tech debt becomes truly problematic, the original authors have most likely moved companies. I think a lot of people know this deep down, which is why so many of them don't go as far to build things on a maintainable way. There's economics for the company, then there's economics for the individual engineer.
- pytester 7y ago
  Similarly, fixing that technical debt will likely look like pure overhead while the benefit of "other people will finish future features faster and with fewer bugs" gets socialized, realized diffusely and goes largely unrecognized (except, if you're lucky, by the other developers themselves). I learned that one the hard way. Features get priority because features have got visibility. The picture gets even worse when you consider the probability that fixing technical debt will break things.
- greggman2 7y ago
  Even if they were still at the same company they'd have moved on or been promoted so it's unlikely they'd be asked to maintain. In my own experience though it is one reason I left my last job. 2 year of new dev, 3 years of maintaince with no end in sight. GPU related stuff, new GPUs come out with new drivers all the time. Working around those bugs so the people using my code don't have to deal with them. There is some feeling of reward but it's mostly no fun. Even in my personal projects the more I have the more maintainance piles on. Browsers break stuff or warnings about libraries. Each project adds X more notifications a month. At some point I'll be overwhelmed with maintainance notificications and have no time for anything else unless I ignore them.
- jacques_chester 7y ago
  This is a collective action problem, which is on their list.
cjfd 7y ago
However, now that interest is low future discounting should also be lower so writing maintainable software should start to look better.
- lifeisstillgood 7y ago
  I have occasionally tried to apply option theory (Black Scholes) to software feature selection. But to be honest the cost / inaccuracy of estimation is so large I think it outweighs any option advantages - but dammit it should work !
- TeMPOraL 7y ago
  I don't think so. Tech debt isn't like real debt, you don't have conspicuous interest rates set by the market or state. Also, "future discounting" of both engineers and managers is driven by career options (i.e. promotions and job-hopping), which don't directly depend on interest rates.
  - tremon 7y ago
    you don't have conspicuous interest rates set by the market or state Not explicitly, but you could say that the interest rate on technical debt is determined by the rate of change in connected components (be it build-time or run-time dependencies, data producers or data consumers).
  - jacques_chester 7y ago
    I'm pretty sure there would be some way to financialise tech debt. You are deliberately incurring future costs in order to realise present benefits.
deleted 7y ago
[deleted]
iamsb 7y ago
> Maintenance doesn't provide immediate economic value Reading Taleb's Skin in the game helped me articulate it to my team and managers how tech debt is a huge risk and need to find sustainable ways to pay it off. For last few years I have insisted on making sure that every sprint one engineer in dedicated to working on maintenance. Also once every year we do a 1% hackthon (2-3 days) where we work on low priority tickets that have not be worked on for a long time. This stops low priority tasks getting starved out. They impact only a very small number of customers, but added up do end up increasing overall satisfaction of all customers.
dwb 7y ago
I don't think we're going to make it on this planet if we think of maintenance as a crazy idea that doesn't make sense in capitalism. We don't have to see capitalism as the be-all and end-all, much as it seems like that right now.
Jach 7y ago
Joel said that in the context of begging programmers to learn some micro-economics. It's fair to treat maintenance as an economic tradeoff, but the keyword is tradeoff: it's not just a list of pros and cons, but interlinked relations (just as supply-demand) where doing more/less of X necessitates more/less of Y. Beyond that real engineering programs will also at least have some sort of 'engineering economics' component that if nothing else exposes one to the fact that say a mechanical engineering company will use present value / future value / maintenance cost / replacement cost / lifetime cost calculations and estimates all the time for machinery and so forth, some of which could be applied to software. Since Joel's "Joel Test" includes things like "Do you fix bugs before writing new code?" I doubt code maintenance was high on his mind when he wrote the bit about crazy ideas. Can any company even answer yes to that these days? Do they have a strong economic argument? (Best I see is "P1 and P2 bugs closed before release".)

by omeid2 7y ago

ravenstine 7y ago

By the time that outstanding tech debt becomes truly problematic, the original authors have most likely moved companies. I think a lot of people know this deep down, which is why so many of them don't go as far to build things on a maintainable way. There's economics for the company, then there's economics for the individual engineer.

pytester 7y ago
Similarly, fixing that technical debt will likely look like pure overhead while the benefit of "other people will finish future features faster and with fewer bugs" gets socialized, realized diffusely and goes largely unrecognized (except, if you're lucky, by the other developers themselves). I learned that one the hard way. Features get priority because features have got visibility. The picture gets even worse when you consider the probability that fixing technical debt will break things.
greggman2 7y ago
Even if they were still at the same company they'd have moved on or been promoted so it's unlikely they'd be asked to maintain. In my own experience though it is one reason I left my last job. 2 year of new dev, 3 years of maintaince with no end in sight. GPU related stuff, new GPUs come out with new drivers all the time. Working around those bugs so the people using my code don't have to deal with them. There is some feeling of reward but it's mostly no fun. Even in my personal projects the more I have the more maintainance piles on. Browsers break stuff or warnings about libraries. Each project adds X more notifications a month. At some point I'll be overwhelmed with maintainance notificications and have no time for anything else unless I ignore them.
jacques_chester 7y ago
This is a collective action problem, which is on their list.

cjfd 7y ago

However, now that interest is low future discounting should also be lower so writing maintainable software should start to look better.

lifeisstillgood 7y ago
I have occasionally tried to apply option theory (Black Scholes) to software feature selection. But to be honest the cost / inaccuracy of estimation is so large I think it outweighs any option advantages - but dammit it should work !
TeMPOraL 7y ago
I don't think so. Tech debt isn't like real debt, you don't have conspicuous interest rates set by the market or state. Also, "future discounting" of both engineers and managers is driven by career options (i.e. promotions and job-hopping), which don't directly depend on interest rates.
- tremon 7y ago
  you don't have conspicuous interest rates set by the market or state Not explicitly, but you could say that the interest rate on technical debt is determined by the rate of change in connected components (be it build-time or run-time dependencies, data producers or data consumers).
- jacques_chester 7y ago
  I'm pretty sure there would be some way to financialise tech debt. You are deliberately incurring future costs in order to realise present benefits.

deleted 7y ago

[deleted]

iamsb 7y ago

> Maintenance doesn't provide immediate economic value Reading Taleb's Skin in the game helped me articulate it to my team and managers how tech debt is a huge risk and need to find sustainable ways to pay it off. For last few years I have insisted on making sure that every sprint one engineer in dedicated to working on maintenance. Also once every year we do a 1% hackthon (2-3 days) where we work on low priority tickets that have not be worked on for a long time. This stops low priority tasks getting starved out. They impact only a very small number of customers, but added up do end up increasing overall satisfaction of all customers.

dwb 7y ago

I don't think we're going to make it on this planet if we think of maintenance as a crazy idea that doesn't make sense in capitalism. We don't have to see capitalism as the be-all and end-all, much as it seems like that right now.

Jach 7y ago

Joel said that in the context of begging programmers to learn some micro-economics. It's fair to treat maintenance as an economic tradeoff, but the keyword is tradeoff: it's not just a list of pros and cons, but interlinked relations (just as supply-demand) where doing more/less of X necessitates more/less of Y. Beyond that real engineering programs will also at least have some sort of 'engineering economics' component that if nothing else exposes one to the fact that say a mechanical engineering company will use present value / future value / maintenance cost / replacement cost / lifetime cost calculations and estimates all the time for machinery and so forth, some of which could be applied to software. Since Joel's "Joel Test" includes things like "Do you fix bugs before writing new code?" I doubt code maintenance was high on his mind when he wrote the bit about crazy ideas. Can any company even answer yes to that these days? Do they have a strong economic argument? (Best I see is "P1 and P2 bugs closed before release".)