
A Hierarchy of Engineering Values - duncan_mcisaac
https://www.duncanmcisaac.com/a-hierarchy-of-engineering-values/
======
andersource
Personally the way I examine dissatisfaction with a project is by comparing my
(mostly subconscious) expectations with reality, then asking why the major
gaps exist. These gaps could sometimes be equivalent to the values mentioned
in the article (e.g. I was expecting to learn this cool new technology but
we're using the same old thing), but many other things could bubble up. E.g.
expectation to spend all day developing new features vs. reality of hunting
down bugs, expectation of everyone agreeing with my opinions vs. reality of
some disagreements, etc. Many times it's surprisingly easy to match my
expectations with reality once the gap is explicit. I've found that the
feeling of disillusionment described is usually the result of my subconscious
finding it progressively harder to ignore the gap between expectations and
reality.

------
harimau777
I think this is a valuable thing for a team to think about and understand.
However, I don't agree that if someone's ranking of these values differs from
others on the team that means that someone should leave.

As I see it, finding ways to accommodate the different goals, outlooks, and
personalities that make up the team is one of the team leader's
responsibilities. After all, there's not really much need for leadership if
everyone is the same.

~~~
closeparen
I work on a team with a portfolio of ~30 separate features and 5 people. I’ve
almost never been in conflicts with my teammates’ values or aesthetic
sensibilities, since we can almost never afford to have two people working on
the same thing. If I’m working on someone else’s code it’s usually because
they’ve left, so I’m free to change it to my liking. When we do surge several
people to a project, there’s still one owner who calls the tune on design,
style, etc. so just not much debate about it. It’s their house; the extra
contributors are just passing through.

We always do code review, so no one goes too far off the reservation, but you
accept diffs that are acceptable in their own context; values disagreements
are nonblocking.

------
29athrowaway
The problems with this hierarchy are:

In the worst case scenario, a bad design or implementation can be the
equivalent of multiplying all effort by zero.

\- It can cause you to be unable to demo a product to a customer, or offer
them the product as a trial period, because the product simply doesn't work or
is unusable.

\- A bad implementation can make you waste all your funding in something you
cannot monetize and leaving you without an exit strategy.

\- A bad implementation can violate regulations and be effectively illegal.

\- A bad implementation can make you lose clients and affect your company
reputation, sometimes permanently. Even if you hire an army of customer
support representatives to contain frustration, or offer refunds, gifts and
discounts, the bleeding won't stop until you fix the implementation.

\- A bad implementation can make it necessary to hire an army of engineers to
implement a simple change, because all your engineers spend 99% of their time
trying to keep the Jenga tower of spaghetti code they can't refactor running.
They cannot refactor it because you told them that "how" is not important.

\- A bad implementation and bad practices can frustrate your engineers and
cause them to actually leave their job.

So, implementation is not only some abstract nerd problem about spaces vs
tabs, it can be an HR problem, a financial problem, a reputation problem, a
legal problem, etc.

~~~
glutamate
That's not how I read the article. The author didn't say that "how you build
it" was at the bottom of the hierarchy or anything like that. They presented
an unordered list of values and asked the reader to rank them.

It sounds like "how you build it" is very important to you, which (as I read
the article, and in my own opinion) is a perfectly acceptable value. That's
the point of value systems, you don't have to agree about them but if there is
a conflict between your values and values of your organisation, be aware of it
because otherwise it will eventually cause conflicts.

------
alfor
Hard to like the answer to any of these question in a large company.

You don't like the product

You don't like the why of the company

You don't like the how it's build.

But, the salary is useful.

------
dynamite-ready
What's particularly pertinent to software engineering, is in `How something is
built` often appears to override `Why something is built` and `What is built`.

Even, not infrequently, in safety critical environments, if some case studies
are to be believed.

~~~
jorangreef
The same is true for bestseller business books, all concerned with the How and
not the Why, when it's the Why that moves the needle.

And you see this blind adherence to "process over purpose" everywhere in
software teams, with things like Agile, Scrum, Kubernetes, microservices etc.
where none of this actually matters to the user.

Henry Ford's autobiography is one of the few that focuses on the Why, and it
is ironic that business schools tend to talk about him in terms of the How
("he revolutionized the production process"). Henry Ford's secret to
everything was not his production process, but the basis on which he conducted
business and approached industry.

The thing is, if you get the Why right, then the How automatically follows: do
things in the most direct way possible with a minimum of red tape.

~~~
the_other
Maybe it’s just me, but I don’t see Scrum prioritising the “how” over the
“why”. It advertises itself as a “how” (and a very flexible, minimal one at
that), in order to get out of your way to focus on the “what” and “why”.
Because it completely avoids speaking to the “why”, adoptees are free to use
it in whatever relation to “why” they see fit. To me it’s clear the “why”
comes first.

I do agree that we find it very easy to talk about “how” ahead of “why”.
Especially those of us whose job it is to make the “what”.

I’d happily dig into whether a “how” does indeed fall out of a “why”. My knee-
jerk reaction was “probably not”, but on A bit of reflection you may be right
in more cases than not. The “why” helps frame customer/user expectation, which
in turn suggests tolerances for usability, functionality and quality, which in
turn should suggest a “how”.

~~~
dynamite-ready
I think problems tend to arise from the following...

\- The clamour over "HOW" something is built, will most certainly shape 'WHAT'
is built

\- After "WHAT" is delivered, it's existence is then found to conflict with
"WHY" in someway (missing features, design made to fit the tooling, people
implementing ideas they feel is right for the user, etc)

Two years later, you're re-writing vast portions of the originally defined
"WHAT", based on a renewed declaration of "WHY".

By this time, the engineering team will have new and innovative ideas related
to "HOW", even though the "WHY" never changed...

But the "WHY" has been forced to move on a great deal, because the "WHAT" made
the original declaration of "WHY" look misguided. Although it wasn't.

Tbh, the "HOW" is extremely hard, which is why this is such a common state of
affairs...

Not sure if that makes any sense, but that was fun to write!

~~~
jorangreef
And it was fun to read!

------
_Adam
"When you build it" is missing from this list. In my experience, the "when"
often tends to take precedence over the "how" and occasionally over the "what"
as well.

------
kevsim
For me, as important as any of these factors is “who are you building it
with”. Great teammates and a great manager can go a really long way towards
job satisfaction.

~~~
jorangreef
"as important as any of these factors"

Surely direction has to be more important?

A great team is great, but not if "we're on a road to nowhere".

And even a good (or possibly mediocre) team with a great direction, a noble
goal, must be better than a great team with a dead-end direction, because
people will sacrifice and put up with all kinds of politics if the cause is
worthy, if there are lives on the line.

~~~
kevsim
That’s a fair point. I guess my point is that even with direction, if I’m not
surrounded by a great team, I’m probably not going to be enjoying my job. Both
of these things for me are more important than the specific problem I’m
solving or whatever tech I’m using to solve it.

------
jorangreef
"How you build it: How much do you value the application of specific
technologies, engineering practices or processes when building software?"

And the inverse: How much do you value doing things in the most direct way
possible with a minimum of specific technologies, dependencies, frameworks,
practices or processes (i.e. red tape)?

------
doublesCs
What is the fundamental reason why a software engineer is expected to care
about what feature he's building, whereas a plumber isn't? Is it due to how
differently the two professions are viewed by society, or is there some
intrinsic difference between the two professions?

(Just don't tell me it's because software engineers are "creative" whereas
plumbers are mindless drones; when faced with a problem, a plumber has to
propose solutions and evaluate trade-offs, same as an engineer)

~~~
claudiulodro
A plumbers' work basically always improves society.

A software developers' work sometimes improves society, sometimes harms
society, and sometimes is a meaningless waste of time. Society encourages
developers to use their judgement and ideally improve society.

At it's core, I think caring about the feature you're making is a judgement on
whether you think the feature will improve the world or not.

------
anhldbk
This reminds me of The Golden Circle by Simon:
[https://simonsinek.com/commit/the-golden-
circle](https://simonsinek.com/commit/the-golden-circle)

~~~
aspenmayer
Could you talk more about it? The site is vague and low info density. It comes
off like The Secret or other kinds of weird neurolinguistic programming ideas
crossed with a multilevel marketing scheme.

~~~
kthejoker2
Here's a TED talk by Sinek on the concept (it turned into a book, Start With
Why, and now a set of courses, etc.)

It's a simple but powerful concept - one of those you should revisit on a
regular basis to test your beliefs and the difference you want to make at
work, in your society, etc.

[https://www.youtube.com/watch?v=u4ZoJKF_VuA&vl=en](https://www.youtube.com/watch?v=u4ZoJKF_VuA&vl=en)

~~~
gherig4
What is Sinek's thesis statement? I don't think this answered the parent
comment's question.

~~~
kthejoker2
I mean, the title of the book is Start With Why. The thesis, I suppose, is
"Starting with why yields better products / results than not."

