[HN Gopher] Developer Productivity for Humans: Software Quality
___________________________________________________________________
Developer Productivity for Humans: Software Quality
Author : saeedesmaili
Score : 112 points
Date : 2023-12-28 09:02 UTC (1 days ago)
(HTM) web link (ieeexplore.ieee.org)
(TXT) w3m dump (ieeexplore.ieee.org)
| techdmn wrote:
| 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 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.
| allsunny wrote:
| 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.
| klabb3 wrote:
| > 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.
| sokoloff wrote:
| > 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."
| kdfjgbdfkjgb wrote:
| what about nonprofits?
| Davidbrcz wrote:
| Nonprofits still need to break even or raise funds
| (membership fees, donations).
| linuxlizard wrote:
| 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.
| ravenstine wrote:
| 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.
| devoutsalsa wrote:
| If raise your prices, cut R&D, and all your disgruntled
| customers leave, customer satisfaction & profits will go up
| in the short term!
| ponector wrote:
| 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.
| whstl wrote:
| > _" 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.
| 0xbadcafebee wrote:
| 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 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.
| galaxyLogic wrote:
| 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.
| krapp wrote:
| >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 employer,_
| not the customer (except where they are the same person,)
| therefore productivity is loosely a measure of the value you
| create for your employer over time.
| bluGill wrote:
| 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 cannot be made until the last of
| that product is sold, but we need it up front to decide if
| we should invest in the engineering.
| marcosdumay wrote:
| 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 and it's incredibly hard for people to improve.
|
| And yet, I've never seen anybody teaching "management" to even
| acknowledging any of the complexity. (Including famous authors
| and professors.)
| crabbone wrote:
| 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 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.
| loup-vaillant wrote:
| Here's the beginning of a metric: https://loup-
| vaillant.fr/articles/source-of-readability
| whstl wrote:
| 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.
| 082349872349872 wrote:
| > _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.
| danielovichdk wrote:
| "...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.
| prmph wrote:
| Code quality is mostly related to maintainability.
|
| A piece of code may be reliable currently, but hard to modify.
| bhupesh wrote:
| Off-topic, but was anyone able to locate Part 3 of this series?
| grork wrote:
| https://ieeexplore.ieee.org/document/10109339 appears to be
| part 3, based on the authors (collin) LinkedIn publications
| list.
| genr8 wrote:
| I liked this article a lot, it really helped to nail down what
| EXACTLY people mean when it comes to metrics.
___________________________________________________________________
(page generated 2023-12-29 23:00 UTC)