5 ms·

You're correct, of course, and the Schumpeter curve is not something I'd heard of (I'm not sure that's the textbook name, but I'm sure it's the same concept) an

You're correct, of course, and the Schumpeter curve is not something I'd heard of (I'm not sure that's the textbook name, but I'm sure it's the same concept) and is kind of interesting and frustrating at the same time. Speaking from a strictly business standpoint I understand the motivation behind these things, but from my day to day programming perspective -- where the revenue doesn't come back to me in any way and building the Next Big Feature is really just looking for a spot for it to fit in among the bramble of previous releases -- all I want is for the software to work better. I tend to think of it as just knowing too much, but maybe it's just time to move on.

click170 11y ago
I'm with you. I'm there to make the software better. But the company is there to make money, and improving the software sadly doesn't always make more money. For me, I fill the need of writing better software by working on Foss projects in my spare time because is satisfies that itch so I don't have to try and satisfy it at work. On the other hand I really feel like this is one thing that makes Foss software better IMO than proprietary software. Foss Devs can spend hours working on something that turns out to have no performance impact at all, the point is they have the freedom to pursue that, and that in corporate development the norm is that those issues just never get raised, let alone fixed.
- mikekchar 11y ago
  Interestingly, I have mostly thought the way you do. In the past few years, though, I've started to change my mind. I've always thought that you could look at it like a graph. On one axis there is software quality and on the other axis there is return on investment. The graph is undefined at 0, but essentially, as you increase software quality, ROI increases. At some point, it starts to dip down -- more quality takes more time, but provides little additional monetary benefit. The sweet spot on the graph depends on the situation, but you are always balancing those two forces. It seems quite obvious that it works that way, but I think that's because we are using a definition of software quality that is not necessarily so useful. In fact, one of the biggest problems we have in this industry is that "good code" is highly subjective. Usually "good code" == "my code" (possibly with the proviso "that I wrote recently"). Similarly, we think that with enough time we will be able to find the perfect design to represent the problem (now and in the future). I think this view is what causes us to come to the wrong conclusion about ROI vs quality. If I define quality in a different way -- the ability for anyone on the team to understand and modify the software quickly, we might find that we have a different looking curve. As I have gotten older, I have discovered that I'm not nearly as confident about my designs as I was when I was younger. Now, I quite often experience the situation where I think, "There are many options for the design here. I don't actually know what is best yet, because we haven't written enough code in this area. So I'm not going to play with it". An earlier version of me would look at the code and conclude that it was sloppy. The new me is trying to avoid locking developers into a design decision that might turn out to be sub-optimal in the long run. In other words, avoiding making a commitment as long as possible (but not longer). Or if you want to look at it a different way, we have all experienced code bases that are hard to work with because they make seemingly arbitrary choices that we have to work around. Or that have unfortunate design decisions that are baked into the code and impossible to refactor out. I will submit that this is generally a result of trying to "do it right" and failing. I work with at least as much of this kind of code as I do with unstable spaghetti code that breaks whenever you breathe on it (the result of abandoning quality). To sum up, I think that as long as your project is going to last for more than about 2 months, good quality code has a much higher ROI than poor quality code. Where we get into trouble is that most developers do not know what good quality code looks like and often over-design/over-commit to the detriment of both the code base and the ROI. I will suggest that at some point, as developers spend more time trying to "do it right", they actually end up with less flexible code that can't react to the surprising requirement changes that are likely to come in the future. Which is not really a helpful insight because it basically says that you need to hire better/more experienced programmers to have good code bases that give you better ROI. ;-)
ArkyBeagle 11y ago
I made up the "Schumpeter curve" thing, so you're unlikely to find it, I'd think. Of course it refers to how long the product/company will be alive and relevant. It wears on people, but guys in combat get used to other people in their outfit dying eventually. This is nothing compared to that. I am extremely sympathetic with wanting it to work better, but again, that which cannot be easily measured does not exist. An alternate strategy is to do this surreptitiously and present it as a fait accompli, but that has risks.
- ry_ry 11y ago
  At some point in history Newton had just made up gravity, and Einstein made up the concept of awful metaphors about driving away from clocks really, really fast. The Schumpeter curve warrants some serious investigation.
  - ArkyBeagle 11y ago
    Gawrsh, Mickey.... nyuk! We could just call it the Firm Death Clock :) Doesn't scan as well, does it?

click170 11y ago

I'm with you. I'm there to make the software better. But the company is there to make money, and improving the software sadly doesn't always make more money. For me, I fill the need of writing better software by working on Foss projects in my spare time because is satisfies that itch so I don't have to try and satisfy it at work. On the other hand I really feel like this is one thing that makes Foss software better IMO than proprietary software. Foss Devs can spend hours working on something that turns out to have no performance impact at all, the point is they have the freedom to pursue that, and that in corporate development the norm is that those issues just never get raised, let alone fixed.

mikekchar 11y ago
Interestingly, I have mostly thought the way you do. In the past few years, though, I've started to change my mind. I've always thought that you could look at it like a graph. On one axis there is software quality and on the other axis there is return on investment. The graph is undefined at 0, but essentially, as you increase software quality, ROI increases. At some point, it starts to dip down -- more quality takes more time, but provides little additional monetary benefit. The sweet spot on the graph depends on the situation, but you are always balancing those two forces. It seems quite obvious that it works that way, but I think that's because we are using a definition of software quality that is not necessarily so useful. In fact, one of the biggest problems we have in this industry is that "good code" is highly subjective. Usually "good code" == "my code" (possibly with the proviso "that I wrote recently"). Similarly, we think that with enough time we will be able to find the perfect design to represent the problem (now and in the future). I think this view is what causes us to come to the wrong conclusion about ROI vs quality. If I define quality in a different way -- the ability for anyone on the team to understand and modify the software quickly, we might find that we have a different looking curve. As I have gotten older, I have discovered that I'm not nearly as confident about my designs as I was when I was younger. Now, I quite often experience the situation where I think, "There are many options for the design here. I don't actually know what is best yet, because we haven't written enough code in this area. So I'm not going to play with it". An earlier version of me would look at the code and conclude that it was sloppy. The new me is trying to avoid locking developers into a design decision that might turn out to be sub-optimal in the long run. In other words, avoiding making a commitment as long as possible (but not longer). Or if you want to look at it a different way, we have all experienced code bases that are hard to work with because they make seemingly arbitrary choices that we have to work around. Or that have unfortunate design decisions that are baked into the code and impossible to refactor out. I will submit that this is generally a result of trying to "do it right" and failing. I work with at least as much of this kind of code as I do with unstable spaghetti code that breaks whenever you breathe on it (the result of abandoning quality). To sum up, I think that as long as your project is going to last for more than about 2 months, good quality code has a much higher ROI than poor quality code. Where we get into trouble is that most developers do not know what good quality code looks like and often over-design/over-commit to the detriment of both the code base and the ROI. I will suggest that at some point, as developers spend more time trying to "do it right", they actually end up with less flexible code that can't react to the surprising requirement changes that are likely to come in the future. Which is not really a helpful insight because it basically says that you need to hire better/more experienced programmers to have good code bases that give you better ROI. ;-)

ArkyBeagle 11y ago

I made up the "Schumpeter curve" thing, so you're unlikely to find it, I'd think. Of course it refers to how long the product/company will be alive and relevant. It wears on people, but guys in combat get used to other people in their outfit dying eventually. This is nothing compared to that. I am extremely sympathetic with wanting it to work better, but again, that which cannot be easily measured does not exist. An alternate strategy is to do this surreptitiously and present it as a fait accompli, but that has risks.

ry_ry 11y ago
At some point in history Newton had just made up gravity, and Einstein made up the concept of awful metaphors about driving away from clocks really, really fast. The Schumpeter curve warrants some serious investigation.
- ArkyBeagle 11y ago
  Gawrsh, Mickey.... nyuk! We could just call it the Firm Death Clock :) Doesn't scan as well, does it?