Something that I find missing in almost every software company is this thing that I'm not sure I've seen explicitly called out anywhere, but I'm going to call it an Engineering Language.
@hazelweakly Clearly defining the abstraction language is difficult because it is the lowest building block. To me, part of this is the technical idea of a product. Like, yes, we're selling tires, but how is that represented within our systems?
That question is something that I've seen people actively avoid. Usually, the software representation of a product is overly complex and understood only by a few. Then, you have segmented provisioning/deprovisioning flows that break without a warn.
@hazelweakly this is really good and i think im going to include it as part of platform eng, soa governance, and product thinking workshop im doing but frankly
"I prefer to think of it internally as an interface and externally as a protocol" is going to really help explain some stuff
@hazelweakly I see I'm not the only one this resonated with (still need to finish reading it and now catch up on the additional convos here!) but this whole thing about how to communicate snowballing thoughts/ideas linearly has been a thing for me lately — thanks for writing this up and starting the discussions!
Like your Description of “human-centered engineering(HCE)”. Anything “human-centered” must have a contextual, multidimensional communication system that carries & shares information about intention-, affect(emotion)-, effect(impact)-, problem framing-, solution choice-, reference blueprints-decision making+trade-offs+opportunity costs.
A factory=all these rigidly pre-decided for 1 specific combination to produce a specific output.
Engineering=creative, decision making endeavour.
@hazelweakly when I read this it’s like the train tracks of my old man brain keep dragging me back to XPs System Metaphor, which feels very much like a liberal arts way to say Engineering Language.
@hazelweakly Awesome work.
Feels related to the Ubiquitous Language of DD, but extended much further. Our abstractions become the language of the domain.
@watters is there anything you think they were doing that fostered this kind of communication, or any of those outcomes you think came from specific kinds of communication?
@mordel@mordel Expanding a bit on "The language was proactively taught and reinforced from day 1" bit—
The key concepts and the labels used for them were written down and well-maintained (in a home-grown Wiki). The utility of this is underrated by most orgs these days.
That meta-documentation was regularly reinforced by referencing it in things like design docs or code review, etc.
Proficiency in the org's lingua franca was valued in the org's culture.
@mordel The other items in my original response weren't coincidences—
There are other elements, like keeping the technology stack stable rather than chasing shiny things and discouraging rather than rewarding promo-driven development.
But, overall, it's incredibly difficult to build alignment at the necessary degree of depth when the median tenure for an engineer is 18 months, no matter how good one's comms and docs practices are.
"Abstractions become useful precisely when they are able to be depended on and ignored, when they are able to be mixed and integrated, built on top of and built around. Abstractions should exist to coexist."
When tenures are short and people are hired primarily from industry, Step 0 is deprogramming their internalized understanding of countless terms, which are commonly believed to have fairly uniform industry-wide definitions but which, in fact, do not.
I'm working with a product brought in via acquisition so it was built with different idioms and definitions. And the team has seen a lot of replacement in a short time with varied backgrounds.
I appreciate your words, I agree it's important to begin with shared understanding!
@hazelweakly something I like to say often is that new words promote new thinking.
The common pattern of taking something we have a name for, and then giving it a new name, is a great way to nudge people to shed existing biases. This works best internally, as you don’t get the peanut gallery trying to keep the old term so much
@glenjamin I think there's definitely something related there! It's definitely one of the reasons you see people rebranding concepts so often, even though the concept is roughly the same, it helps people's interpretations from getting warped
The Engineering Language is something that I would consider to be a living embodiment of how engineers speak, think, describe, and express in that problem domain. It's not a programming language, or a DSL; it's similar to a Design Language, but for engineering and architecture more directly. The Engineering Language is the tool that you use to build foundations of thought and mental models and concepts themselves, so that one can coordinate the intangible nothingness of abstraction itself.
I think this Engineering Language is comprised of three things: An abstraction language, a protocol language, and an interface language. Together, those three things make up something that is greater than the sum of its parts.
I'm going to switch gears for a second and talk about a theoretical business. Imagine this business, which is going to solve a problem, with a product or a service or whatnot, and tackle a certain market. In order to do so, one might start writing some software and doing some market research, validating things, learning about the domain, and so on.
Something curious will eventually happen: No matter how carefully one writes the software, or how adaptable one tries to remain, the company will eventually reach two critical points of solidity:
Some evolution in the software will disproportionately become exponentially difficult relative to its "actual" complexity
Some evolution in market strategy, positioning, or product development, will disproportionately become exponentially difficult relative to its "actual" complexity
But somehow, this isn't the case with language? It isn't the case with the things we learn? How? How is it so different?
If we are to achieve this sort of linearity of growth as knowledge for a business domain develops, and if we are to do so in a way that lets us express this knowledge and make it concrete through computation, then surely we need a language of some sort. An Engineering Language.
@hazelweakly A thousand times yes to your post. You have put much better words to concepts I could only hand wave about. In my org, we shape our CX role to use the tools of design (facilitating empathy, interpretative diagrams, consistent documentation, imagining metaphors) to try and make mutual sense between Business/Design/Eng in every project. Now I see we’re try to build the Rosetta Stone of those languages! Thank you for this!
At the very least i recommend the Stella Report, especially the diagrams Dr Cook make explaining the above-the-line/below-the-line. Also Behind Human Error is a really accessible book, if packed.
Also i am available to answer questions, be a sounding board in this exploration, etc. use the ressources ;)
@hazelweakly In some aspects, our language capabilities as humans aren't so different. Language acquisition has that sort of solidification effect. Spend time in a language environment at a young enough age, and you speak fluently with no accent relative to the community. Same thing as an adult, most people will never get there.
@codefolio@hazelweakly Yep, 100% agreed — it’s all about recognizing that your company already has an ideolect, and that engineering needs to adopt it before it can hope to help steer it.
Naming is one of the most difficult problems in software, and it’s mostly because we think it’s a skill someone one engineer can be good at in isolation.
Add comment