A Hierarchy of Engineering Values(duncanmcisaac.com) |
A Hierarchy of Engineering Values(duncanmcisaac.com) |
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.
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.
Lots of people emphasize the "what"/"why" when talking about software engineering ethics, and lament that everyone only ever talks about the "how". I think that view kinds of misses the point. The three questions are rarely completely separate. Plus, for most engineering projects most folks will work on throughout their career, the "what" and "why" are extremely straight-forward and at least relatively uncontroversial. The "how" (good security, good uptime, etc.) is by far the most important question.
The use of the word “agree” suggests that the article says the thing you say you don't agree with but it doesn't.
The importance (to be fair, absolute importance is probably more important than ranking here) of the questions is important to ubderstabing how much you can or cannot accept divergence in the subject matter of each question between your preference and that of (or imposed on, for those where the decision comes from outside) the team.
And the same works in reverse for the team’s perceived importance of each question and their ability to accommodate/tolerate divergence from you.
So understanding the ranking, yours and the teams, is important to understanding fit, but fit isn't driven by alignment of the rankings (in fact, to the extent that there is disagreement in preferences, it is ideal that your importance order is inverted from the teams—that you are flexible where the team is inflexible, and vice versa.)
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.
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.
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.
Even, not infrequently, in safety critical environments, if some case studies are to be believed.
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.
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”.
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.
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)?
(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)
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.
Software can help in more situations and hence gets prompted by a wider range of “why”. I doubt you could list all the reasons for software to exist before the heat death of the universe overtook you.
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.
- 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!