Developer Productivity for Humans: Software Quality
ieeexplore.ieee.org
Developer Productivity for Humans: Software Quality
1–10 of 51 posts
Re: Developer Productivity for Humans: Software Quality
#2In my experience few things sap developer motivation quite the same way as being forced to support, but not allowed to fix(!), a low quality product. The business rationalization makes a certain sort of sense. If we burn, say, 4 hours a week manually cleaning up after bug X, but it would take 80 hours to fix it, maybe the return on investment doesn't compete well against other initiatives this quarter. But in my experience, it often sends a message that we don't care about our users or our products. That isn't something engineers can be proud of at the end of the day, and it makes it difficult to care about your work. This can obviously be overdone in the other direction as well, but I often find the analysis to be penny wise but pound foolish.
Re: Developer Productivity for Humans: Software Quality
#3In my experience few things sap developer motivation quite the same way as being forced to support, but not allowed to fix(!), a low quality product. The business rationalization makes a certain sort of sense. If we burn, say, 4 hours a week manually cleaning up after bug X, but it would take 80 hours to fix it, maybe the return on investment doesn't compete well against other initiatives this quarter. But in my expe…
The inconvenient truth is that the business exists not to provide engineers with work they’re happy with or proud of but to make investors money. The good news is developer happiness is associated with increased productivity and reduced attrition which usually factors into the business calculus in a much bigger way.
Re: Developer Productivity for Humans: Software Quality
#4In my experience few things sap developer motivation quite the same way as being forced to support, but not allowed to fix(!), a low quality product. The business rationalization makes a certain sort of sense. If we burn, say, 4 hours a week manually cleaning up after bug X, but it would take 80 hours to fix it, maybe the return on investment doesn't compete well against other initiatives this quarter. But in my expe…
I know it's ridiculous, but I will use my own time to work on some problems that officially we're not allowed to fix. I make that issue my hobby project and use my time to learn some new tool/technology (that looks good on a resume). For example, right now I'm learning Rust to fix [a hairy build problem]. Taking on the problem gives me back some that developer motivation. Using it as a learning opportunity makes me feel like I'm personally growing.
Re: Developer Productivity for Humans: Software Quality
#5If you're going to worry about software quality, you need to stop talking about developer productivity, and start talking about business productivity. You can't objectively measure the productivity of a worker in isolation. You have to measure whether the productivity of a worker increases the overall value of the business, or whatever goals the business has.
It goes like this:
1. "We need to improve how fast developers release features". Ok, so we throw out tests. Now they're shipping fast!
2. "We need to improve the quality of developers' code". Ok, so we add quality gates. Now they're shipping better code!
3. "The quality gates are slowing down productivity." Ok, so we'll introduce them at earlier stages, shifting left. Now they're shipping better code faster!
4. "The software works, but the customer is unhappy with the product." Ok, we'll focus on giving the customer regular updates and validating the results are what they expect. Now they're shipping better code faster that the customer likes!
5. "The software is now much more expensive than it used to be." Ok, so we...
...and on, and on. Each time, because nobody is focusing on the entire value chain, only a single thing is getting fixed, and it ends up having knock-on effects. It's not enough to perfect one link in the chain. The whole chain needs to be strong, and communication needs to go both directions, constantly.
Re: Developer Productivity for Humans: Software Quality
#6Here are some comments in no specific order:
* A sample of 9 developers, especially all working for the same company (in similar conditions) isn't much... but this seems to be a sore spot for most research on software development: very small, bordering on unrepresentative samples. Very hard to control for bias. Very hard to establish whether experiment subjects even have the relevant knowledge.
* I would very much prefer if code quality wasn't about people's feelings. There's nothing wrong with people's feelings... except I want a metric. It seems like the authors either don't believe it's possible to capture code quality "impartially" or that we are long way away from being able to do so.
* In the end of the day, the research behind the article doesn't have "action items". Suppose the reader didn't know about the complexities of measuring quality -- then they would've learned how hard it is. But the article doesn't as much as suggest what needs to be done to measure the quality (better). It's hard to fault the authors for not suggesting anything in this regard, and by their own admission, the metrics that they've found so far are kind of a snake oil... But, I really want a metric. That's why others keep pumping that snake oil.
Anyways, I still find the article useful in case anyone needs a brief explanation of the difficulties of assessing software quality.
Re: Developer Productivity for Humans: Software Quality
#7In my experience few things sap developer motivation quite the same way as being forced to support, but not allowed to fix(!), a low quality product. The business rationalization makes a certain sort of sense. If we burn, say, 4 hours a week manually cleaning up after bug X, but it would take 80 hours to fix it, maybe the return on investment doesn't compete well against other initiatives this quarter. But in my expe…
The inconvenient truth is that the business exists not to provide engineers with work they’re happy with or proud of but to make investors money. The good news is developer happiness is associated with increased productivity and reduced attrition which usually factors into the business calculus in a much bigger way.
> The inconvenient truth is that the business exists not to provide engineers with work they’re happy with or proud of but to make investors money.
First that’s not always technically true because not all businesses have investors.
But assuming that the primary purpose is to make money, even that’s not precise since there’s a massive difference on optimizing for ROI tomorrow vs next quarter vs when you retire and hand your business over to others. Or different metrics altogether like market share or “engagement”. Those are all conflicting goals and have changed a lot just in a decade.
But even if you decide precisely which metric to aim for, there’s still a giant difference between primary purpose and only purpose. Simple things like a circuit breaker or a nail might be single purpose. But as soon as you step up almost everything is multi-purpose. A car, a house, even a hat have many degrees of freedom. A business has many unquantifiable components.
Anyway, the point is that giving carte blanche to decisions labeled with “business reasons” is at best lazy, and at worst legitimizes a sort of pseudo religious cargo cult worship of the “business truths” of the current year.
The truth is that nobody sits on magical predictive abilities, neither the 10x engineers nor the MBA grand poobahs. But it’s also clear that the companies with technical leadership and/or a high degree of engineering agency have been so successful in the last two decades, to the point of redefining the nature of business itself.
Re: Developer Productivity for Humans: Software Quality
#8In my experience few things sap developer motivation quite the same way as being forced to support, but not allowed to fix(!), a low quality product. The business rationalization makes a certain sort of sense. If we burn, say, 4 hours a week manually cleaning up after bug X, but it would take 80 hours to fix it, maybe the return on investment doesn't compete well against other initiatives this quarter. But in my expe…
Yet if you make that argument to the business itself, they'll say "but we're making record profits and customer satisfaction is up!", confusing the quality and longevity of the product for their ability to market said product and craft customer surveys.
Re: Developer Productivity for Humans: Software Quality
#9Earlier quoted context omitted.
The inconvenient truth is that the business exists not to provide engineers with work they’re happy with or proud of but to make investors money. The good news is developer happiness is associated with increased productivity and reduced attrition which usually factors into the business calculus in a much bigger way.
> The inconvenient truth is that the business exists not to provide engineers with work they’re happy with or proud of but to make investors money. First that’s not always technically true because not all businesses have investors. But assuming that the primary purpose is to make money, even that’s not precise since there’s a massive difference on optimizing for ROI tomorrow vs next quarter vs when you retire and han…
> not all businesses have investors.
If I form a business and take no outside money, I am the investor, particularly in the context of GP’s point that “[businesses exist]…to make investors money.”
Re: Developer Productivity for Humans: Software Quality
#10Here are some comments in no specific order: * A sample of 9 developers, especially all working for the same company (in similar conditions) isn't much... but this seems to be a sore spot for most research on software development: very small, bordering on unrepresentative samples. Very hard to control for bias. Very hard to establish whether experiment subjects even have the relevant knowledge. * I would very much pr…
Here's the beginning of a metric: https://loup-vaillant.fr/articles/source-of-readability