
Values Are the Rules You Break - D_Guidi
https://8thlight.com/blog/stephen-prater/2020/09/15/values-rules-break.html
======
finnthehuman
>Usually, this isn't because your developers don't understand "the rules" and
/ or don't like you—it's because they know what the organization values, and
those values are in conflict with your "rules," and they're trying to deliver
that value.

I'm bailing out here. Tautological statements that your actions already
represent your desires are a rhetorical tarpit.

After the unnecessary effort to work backwards from what was originally
communicated, it will become one of:

A) A narrow message presented as a wide message

B) a motivating lie meant to reinvigorate people into working on second order
desires

C) an unnecessarily bold proclamation that the process of change is
complicated (and you might be setting yourself up for failure)

D) obviously incoherent and unfounded rubbish which ought to be ignored

------
MaxBarraclough
> There's a military axiom—"You can dictate results or you can dictate
> process, but not both.

This certainly doesn't apply to the domain of critical-systems software
engineering. I realise the emphasis of the article is meant to be agile
methods, but the claims made seem quite categorical, and they don't hold up.

The most well-known coding-standard of this sort is MISRA C. NASA has one too,
as does the Joint Strike Fighter project, and there are plenty of others. When
these standards are taken seriously, developers aren't permitted to treat them
as mere guidelines.

Plenty of organisations may be sloppy with their enforcement of coding
standards. It's also possible for bad standards to be actively
counterproductive. That doesn't mean they're always misguided and always
impossible to enforce.

> The problem with abandoning the fear of failure is that it requires trusting
> our developers, a lot.

I defer to an excellent article on critical-systems software development: [0]

> _the culture is equally intolerant of creativity, the individual coding
> flourishes and styles that are the signature of the all-night software
> world. “People ask, doesn’t this process stifle creativity? You have to do
> exactly what the manual says, and you’ve got someone looking over your
> shoulder,” says Keller. “The answer is, yes, the process does stifle
> creativity.”_

> Real software quality is not a set of shared rules, but a set of shared
> values.

There's a reason avionics software development does not share this contempt
for rules. Of course, there's far, far more to building life-and-death
software than just following a coding-standard, but still.

[0] [https://www.fastcompany.com/28121/they-write-right-
stuff](https://www.fastcompany.com/28121/they-write-right-stuff)

