4 ms·

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.

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. ;-)

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. ;-)