7 ms·

"...time that could be better spent working on new features and shipping new code" Can we please stop putting forth this idea that features >>> reliable produc

"...time that could be better spent working on new features and shipping new code" Can we please stop putting forth this idea that features >>> reliable product? The amount of dev time that a company will save from removing technical debt will likely be more than the extra sales the company will get from a new feature. I look forward to the day where the executive team comes to the developers and ask why they are working on features instead of cutting down technical debt.

ajdlinux 10y ago
"The amount of dev time that a company will save from removing technical debt will likely be more than the extra sales the company will get from a new feature." Not always true (though it often is!), but particularly not always true in the timespan that the company needs to get sales in...
- PhilipA 10y ago
  The problem is that this is very hard to measure. You can't really measure how much time you save on new features after you fixed the old spaghetti-code.
iMerNibor 10y ago
technical debt will not always manifest itself as instability/bad product. It might just affect development time of things interacting with the bad, old code - or make bugs harder to fix Changes to old nasty code will probably be hacky under the mentality "we're going to refactor this anyways, no point in writing clean code /now/" Most old code (i've worked with) will function fine - it has for a while after all.
bigiain 10y ago
There is an old Joel On Software blog post I was reading recently that talked about a methodology at Microsoft they called "Zero defects", where fixing known bug _alway_ had priority over working on new features. <google google google> Here - pont 5 in this post: http://www.joelonsoftware.com/articles/fog0000000043.html http://www.joelonsoftware.com/articles/fog0000000043.html
- BurningFrog 10y ago
  That's by far the best way to work. It's hard to explain to someone who hasn't experienced it how much easier it is to develop in a bug free code base.
  - wcdolphin 10y ago
    I challenge that; I don't think a "bug free code base" actually exists. Joshua Bloch has a great article about this which I think may be of interest to other readers: https://research.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html https://research.googleblog.com/2006/06/extra-extra-read-all.... To paraphrase: We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are great. Static analysis is great. But none of these things alone are sufficient to eliminate bugs: They will always be with us. A bug can exist for half a century despite our best efforts to exterminate it. We must program carefully, defensively, and remain ever vigilant.
    - tonyedgecombe 10y ago
      I don't think Spolsky was saying their product is bug free, just that they won't tolerate having known bugs.
      - bigiain 10y ago
        Not even quite "won't tolerate having known bugs" - it's fundamentally acknowledging that you will at times find bugs in your code base - but that when you do discover bugs you'll prioritise fixing them above adding new features or hitting pre-set project deadlines. It's a great philosophy or methodology, but it can be very hard to execute on 100%. In the real world there are deadlines and resource requirements and impatient clients and produce launch plans with set dates and trade shows starting next week and the Thanksgiving/Xmas launch opportunity and and and.
    - lmm 10y ago
      That bug exists because it's written in a language where + is permitted to silently do surprising things, for reasons that made sense as a performance optimization for general-purpose computers in the '70s and embedded systems in the '90s (the original target of Java) but do not make sense for general-purpose computers today. Better languages are possible. Provably correct software is possible. We really can eliminate bugs.
r00fus 10y ago
> I look forward to the day where the executive team comes to the developers and ask why they are working on features instead of cutting down technical debt. I had a Philippino friend who told me of his early experience in a Japanese development outfit - the team got praised by management (maybe not CEO) on performance improvements and code reduction. At the time I thought those priorities would never have flown in the US (though was of like thinking). So this mindset does/did exist.
- bmj 10y ago
  Do you know what sort of project/product the team produced? I find that to be a key indicator of what sort of work management expects. If are building something that will be sold, particularly in a competitive market, management will almost always believe that new features trump reducing technical debt. To a product manager, even four weeks of technical debt reduction sounds like "no new features for a month."
  - douche 10y ago
    Sometimes it's a struggle to get blessing for four days of technical debt reduction...
  - initram 10y ago
    >To a product manager, even four weeks of technical debt reduction sounds like "no new features for a month." Yeah, but if you can't implement new features in under a month because the code is such a mess, then maybe spending a month cleaning it up will allow you to do more features in a shorter amount of time, thus increasing revenue faster than just hacking more features into the existing crappy codebase. Obviously it depends on the codebase, but you have to look at both long and short term goals to make good decisions.
InclinedPlane 10y ago
There's a pervasive idea that software is just a laundry list of features. This idea isn't just wrong, it's dangerous. You can pick lots of examples of software where the competitors are in theory feature comparable but the experience of using one is vastly superior to the other, with a consequent huge impact on market success.
Ericson2314 10y ago
Yes! 3M is way way way too much, and too few viscerally feel this. Yelp is far from the only offender, of course.
bachback 10y ago
yes, please! can we then also get rid of the notion that there exists a linear design space called "features", and a linear error space called "bugs"? architecture, protocols, security, etc. can all be considered dimensions.
bahjoite 10y ago
Agreed. If you want to spend more time working on features, don't accrue technical debt - or pay it off early.
jbhatab 10y ago
This may or may not be true. Just depends.
akamaozu 10y ago
How best would you go about objectively convincing the executive team that it's better in the long run to invest a bit in stability now? Very new to talking with execs and I don't know where to begin.

ajdlinux 10y ago

"The amount of dev time that a company will save from removing technical debt will likely be more than the extra sales the company will get from a new feature." Not always true (though it often is!), but particularly not always true in the timespan that the company needs to get sales in...

PhilipA 10y ago
The problem is that this is very hard to measure. You can't really measure how much time you save on new features after you fixed the old spaghetti-code.

iMerNibor 10y ago

technical debt will not always manifest itself as instability/bad product. It might just affect development time of things interacting with the bad, old code - or make bugs harder to fix Changes to old nasty code will probably be hacky under the mentality "we're going to refactor this anyways, no point in writing clean code /now/" Most old code (i've worked with) will function fine - it has for a while after all.

bigiain 10y ago

There is an old Joel On Software blog post I was reading recently that talked about a methodology at Microsoft they called "Zero defects", where fixing known bug _alway_ had priority over working on new features. <google google google> Here - pont 5 in this post: http://www.joelonsoftware.com/articles/fog0000000043.html http://www.joelonsoftware.com/articles/fog0000000043.html

BurningFrog 10y ago
That's by far the best way to work. It's hard to explain to someone who hasn't experienced it how much easier it is to develop in a bug free code base.
- wcdolphin 10y ago
  I challenge that; I don't think a "bug free code base" actually exists. Joshua Bloch has a great article about this which I think may be of interest to other readers: https://research.googleblog.com/2006/06/extra-extra-read-all-about-it-nearly.html https://research.googleblog.com/2006/06/extra-extra-read-all.... To paraphrase: We programmers need all the help we can get, and we should never assume otherwise. Careful design is great. Testing is great. Formal methods are great. Code reviews are great. Static analysis is great. But none of these things alone are sufficient to eliminate bugs: They will always be with us. A bug can exist for half a century despite our best efforts to exterminate it. We must program carefully, defensively, and remain ever vigilant.
  - tonyedgecombe 10y ago
    I don't think Spolsky was saying their product is bug free, just that they won't tolerate having known bugs.
    - bigiain 10y ago
      Not even quite "won't tolerate having known bugs" - it's fundamentally acknowledging that you will at times find bugs in your code base - but that when you do discover bugs you'll prioritise fixing them above adding new features or hitting pre-set project deadlines. It's a great philosophy or methodology, but it can be very hard to execute on 100%. In the real world there are deadlines and resource requirements and impatient clients and produce launch plans with set dates and trade shows starting next week and the Thanksgiving/Xmas launch opportunity and and and.
  - lmm 10y ago
    That bug exists because it's written in a language where + is permitted to silently do surprising things, for reasons that made sense as a performance optimization for general-purpose computers in the '70s and embedded systems in the '90s (the original target of Java) but do not make sense for general-purpose computers today. Better languages are possible. Provably correct software is possible. We really can eliminate bugs.

r00fus 10y ago

> I look forward to the day where the executive team comes to the developers and ask why they are working on features instead of cutting down technical debt. I had a Philippino friend who told me of his early experience in a Japanese development outfit - the team got praised by management (maybe not CEO) on performance improvements and code reduction. At the time I thought those priorities would never have flown in the US (though was of like thinking). So this mindset does/did exist.

bmj 10y ago
Do you know what sort of project/product the team produced? I find that to be a key indicator of what sort of work management expects. If are building something that will be sold, particularly in a competitive market, management will almost always believe that new features trump reducing technical debt. To a product manager, even four weeks of technical debt reduction sounds like "no new features for a month."
- douche 10y ago
  Sometimes it's a struggle to get blessing for four days of technical debt reduction...
- initram 10y ago
  >To a product manager, even four weeks of technical debt reduction sounds like "no new features for a month." Yeah, but if you can't implement new features in under a month because the code is such a mess, then maybe spending a month cleaning it up will allow you to do more features in a shorter amount of time, thus increasing revenue faster than just hacking more features into the existing crappy codebase. Obviously it depends on the codebase, but you have to look at both long and short term goals to make good decisions.

InclinedPlane 10y ago

There's a pervasive idea that software is just a laundry list of features. This idea isn't just wrong, it's dangerous. You can pick lots of examples of software where the competitors are in theory feature comparable but the experience of using one is vastly superior to the other, with a consequent huge impact on market success.

Ericson2314 10y ago

Yes! 3M is way way way too much, and too few viscerally feel this. Yelp is far from the only offender, of course.

bachback 10y ago

yes, please! can we then also get rid of the notion that there exists a linear design space called "features", and a linear error space called "bugs"? architecture, protocols, security, etc. can all be considered dimensions.

bahjoite 10y ago

Agreed. If you want to spend more time working on features, don't accrue technical debt - or pay it off early.

jbhatab 10y ago

This may or may not be true. Just depends.

akamaozu 10y ago

How best would you go about objectively convincing the executive team that it's better in the long run to invest a bit in stability now? Very new to talking with execs and I don't know where to begin.