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

41–50 of 51 posts

Re: Developer Productivity for Humans: Software Quality

#41

Post by sam_bristow »

082349872349872 wrote: post #19
whstl wrote: post #13

Earlier quoted context omitted.

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

Every layer of indirection needs to earn its keep. I hate working in codebases which are full of indirection without abstraction, you spend so long hunting for the bit of code that actually _does_ something.

Re: Developer Productivity for Humans: Software Quality

#42

Post by PH95VuimJjqBqy »

bluGill wrote: post #28
krapp wrote: post #21

Earlier quoted context omitted.

>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? No, your productivity has no connection to sales unless your job is in sales. And productivity for individual employees is measured all the time, across all industries. Your time and output is being paid for by your e…

Proxies of productivity are measured. what really matters is total net profit over tha life of the work. For sales this is easy to measure, and for production factoriy workers it isn't too hard. But for most jobs it is hard. Even simple acts like greasing machines is hard to measure how it affcts profits (an actountant can do it, but at the cost of an actountant is it worth measuring) for engingineering the measure c…

in that sense everything is a proxy and the word ceases to have any meaning.

This is a class "the whole is greater than the sum of its parts". You're talking about productivity as a whole, everyone else is talking about productivity of the individual parts. The two are related but independent.

Re: Developer Productivity for Humans: Software Quality

#43

Post by PH95VuimJjqBqy »

sam_bristow wrote: post #41
082349872349872 wrote: post #19

Earlier quoted context omitted.

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

Every layer of indirection needs to earn its keep. I hate working in codebases which are full of indirection without abstraction, you spend so long hunting for the bit of code that actually _does_ something.

> Every layer of indirection needs to earn its keep.

So much this. One of the things I absolutely hate seeing are the use of interfaces with a single concrete implementation.

context matters, it makes sense if you're authoring a library, it can make sense if you're working in something overly dynamic such as Ruby, Python, et al, but in a language like C#, Java, C++, et al, the compiler will assist you if you ever find yourself needing a second concrete implementation and most likely if you DO end up needing that second implementation, the interface is going to change anyway.

Re: Developer Productivity for Humans: Software Quality

#44

Post by galaxyLogic »

endofreach wrote: post #30
krapp wrote: post #21

Earlier quoted context omitted.

>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? No, your productivity has no connection to sales unless your job is in sales. And productivity for individual employees is measured all the time, across all industries. Your time and output is being paid for by your e…

Why so complicated? Productivity per se has nothing to do with sales or employment at all. I can be very productive writing poems for myself. High Productivity = Spent effort results in progress towards the desired outcome (the product). The question is: What is the product? I believe the issue is, that many (software) company are confused about that. Their product is the invoice. Everything else – especially the sof…

You can be very productive writing poems but how do you measure your productivity? Number of lines you write per day?

Similarly in software development it is commonly understood that the lines-of-code is a bad metric for productivity. Some people write many lines while others may eliminate lines from it.

In general "productivity" is about economic activity and thus measured in monetary terms. But that doesn't make it any simpler.

Re: Developer Productivity for Humans: Software Quality

#46

Post by nine_zeros »

sam_bristow wrote: post #39
nine_zeros wrote: post #36

Earlier quoted context omitted.

> Having accountability without control My manager: I want this in X days Me: It is unlikely to finish in X days given x,y,z. It is also likely to cause outages. My manager: If it causes outages, we will throw you on a PIP. Me gets burned out. Lesson learned. If a manager forces me ever again, I am going to let the project and the manager fail.

It sucks when you're in that situation, but sometimes a paper-trail and a dose of failure is the only way people learn.

The real problem is too much power to management without accountability. If the team suffers due to management decisions, how about we yank the management first?

Re: Developer Productivity for Humans: Software Quality

#47

Post by 0xbadcafebee »

marcosdumay wrote: post #25
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…

Actual management is hard! Companies are completely chaotic systems, and every important feature comes as much from the details as they do from the big picture. Most people are completely unable to work with that, what includes a large majority of the managers on every level. Worse yet, it's never clear if a good or bad result happened because of somebody's work or despite it, so the feedback is completely unreliable…

I think W.E. Deming had some very good practical advice that I rarely see actioned. One place I worked, there was an entire volume of Deming's books on a shelf you had to pass to get to the cafeteria. But his advice wasn't being heeded. Why is that?

My thinking is, there's often enough people working for a business that know what the problems are, and can figure out how to solve them. But they can't solve them if they don't have the authority to do so, or their superiors stop them, or nobody cooperates with their attempts. I don't know how to solve that, but it must have to do with agency and cooperation.

Re: Developer Productivity for Humans: Software Quality

#48

Post by whstl »

nine_zeros wrote: post #46
sam_bristow wrote: post #39

Earlier quoted context omitted.

It sucks when you're in that situation, but sometimes a paper-trail and a dose of failure is the only way people learn.

The real problem is too much power to management without accountability. If the team suffers due to management decisions, how about we yank the management first?

But also: There is often zero practical need for rushing things, or for having some complicated vanity feature. This way there is a lot of risk and accountability as far as the team is concerned, but there was nobody up the chain asking for it.

The game of Chinese Whispers of features (and deadlines!) is probably the most inefficient part of software development.

Re: Developer Productivity for Humans: Software Quality

#49

Post by uticus »

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

Pretty good but regurgitated design patters overall, I'm not impressed. Moreover I personally find the part about "Don’t waste vertical space" too far gone, it would be better to switch to a more terse language like APL or derivative if wasted space is the impediment it's made out to be here.

Re: Developer Productivity for Humans: Software Quality

#50

Post by pdimitar »

linuxlizard wrote: post #4
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…

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

It's not at all ridiculous but at the end of the day it turns out that our excitement for our craft is turned against us (as in making us work more hours for no extra pay or anything at all really except a little better resume as you said; and the cases where the resume gets enriched are IMO super rare).
Post reply on HN