Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Developer Productivity for Humans: Software Quality

ieeexplore.ieee.org

Post reply on HN
Print view View original

11–20 of 51 posts

Re: Developer Productivity for Humans: Software Quality

#11

Post by ponector »

techdmn wrote: post #2

In 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…

After 10+ years of working as a QA engineer I accepted that every project, every piece of software is a crap, is full of bugs, many of which are not going to be fixed.

The difference is only how shitty it is. Internal software of huge corporations are total crap. Software which is facing paying customers is better.

Re: Developer Productivity for Humans: Software Quality

#12

Post by whstl »

techdmn wrote: post #2

In 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…

> "being forced to support, but not allowed to fix"

IMO that's a super important point. Having accountability without control is probably the fastest way to burnout and dissatisfaction in my experience. It doesn't matter the amount of hours you put in, it doesn't matter how much vacation you have. It's the difference between a feeling of accomplishment vs the learned helplessness and Sisyphean feeling of endlessly pushing a stone uphill.

And productivity suffers the most. This situation negatively affects the whole system, naturally.

Re: Developer Productivity for Humans: Software Quality

#13

Post by whstl »

loup-vaillant wrote: post #10
crabbone wrote: post #6

Here 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

Wow, that's a good list. I agree with all of those, and am bookmarking this to show to others.

On the subject of deep modules, as also recommended by John Ousterhout, I also enjoy a side effect of this approach: flatter dependency trees (internal dependencies). If you have deeper modules, you stop needing 10, 20 levels of modules to accomplish things. Not needing this makes it easier to debug and understand the big picture. IMO, "big picture code readability" is something of an afterthought. Things like Clean Code only care about the "small picture", individual classes and methods. Things that are rarely a problem in practice IMO.

Flatter hierarchies also reduces the number of things to maintain/understand: in the frontend, for example, a flat component hierarchy removes the need for components far away in the hierarchy to communicate, so no need for Redux (also no prop-drilling). It also makes things like DI containers not strictly necessary, as you can easily do it manually, if you have fewer layers.

Another important thing I realized is flatter hierarchies allow making that dependency graph closer to a tree, rather than a cyclic graph. This reduces cross-cutting concerns and minimizes incidences of "surprise code" that are often super deep into the dependency tree and a common source of bugs.

All IMO and IME, of course. But I'm curious if you also share my experience.

Re: Developer Productivity for Humans: Software Quality

#14

Post by danielovichdk »

"...or that reliability may not even fully depend on code quality at all (“I’ve seen lots of reliable code that’s poor quality.”) They indicated that while these are related, they are not the same concept as “code quality.”"

Something being more reliable than something else is an absolute quality measure.

Re: Developer Productivity for Humans: Software Quality

#15

Post by devoutsalsa »

ravenstine wrote: post #8
techdmn wrote: post #2

In 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.

If raise your prices, cut R&D, and all your disgruntled customers leave, customer satisfaction & profits will go up in the short term!

Re: Developer Productivity for Humans: Software Quality

#18

Post by kdfjgbdfkjgb »

sokoloff wrote: post #9
klabb3 wrote: post #7

Earlier 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. 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.”

what about nonprofits?

Re: Developer Productivity for Humans: Software Quality

#19

Post by 082349872349872 »

whstl wrote: post #13
loup-vaillant wrote: post #10

Earlier quoted context omitted.

Here's the beginning of a metric: https://loup-vaillant.fr/articles/source-of-readability

Wow, that's a good list. I agree with all of those, and am bookmarking this to show to others. On the subject of deep modules, as also recommended by John Ousterhout, I also enjoy a side effect of this approach: flatter dependency trees (internal dependencies). If you have deeper modules, you stop needing 10, 20 levels of modules to accomplish things. Not needing this makes it easier to debug and understand the big p…

> If you have deeper modules, you stop needing 10, 20 levels of modules to accomplish things.

I'm a big fan of being able to read stack traces without scrolling, so my rules of thumb are to remove layers that pass data around without either providing a substantial abstraction or doing some computation with it (avoid ravioli code), and to collapse layers that were all doing the same sort of thing to the data, each a little bit at a time (avoid salami code).

My bet is that shallow modules originate via Conway's Law, then get cargo culted.

Re: Developer Productivity for Humans: Software Quality

#20

Post by galaxyLogic »

0xbadcafebee wrote: post #5

If 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 develop…

I find the concept of "productivity" fascinating. It must be measured in money because (positive) productivity means someone is paying for what you are doing.

And in that sense you cannot measure the productivity of a single person alone, you must measure what people are willing to pay for their output.

If you produce exactly the same as you did last month but nobody is buying it this month (or ever again) it means your productivity is zero. Is that true? Or does it mean your productivity is negative?

Or is it the case that when you work for someone else your productivity can be measured by the salary they are paying you? That would mean that "productivity is in the eye of the beholder". Your productivity as seen by you is different than your productivity measured by your employer.

Post reply on HN