In an attempt to gain an understanding of the software design he was carrying around in his head, I sat down with a colleague and started talking face to face with him. To facilitate the conversation, I started sketching my emergent understanding of his design in my notebook. As you can see, by the time we finished talking, 20 minutes later, I ran out of ink and I wasn’t much better off than before we started the conversation:
If I had a five year old son, I would proudly magnetize my sketch on the fridge right next to his drawings.
To illustrate the difference between analytical thinking and systems thinking (which some people think are identical), Jamshid Gharajedaghi presents these two figures in his wonderful book: “Systems Thinking: Managing Chaos and Complexity“.
Anyone who has been through high school has been exposed to equations of the type on the left. To discover the impact of one variable, say x1, on the system output, y, you simply vary its value while keeping the values of the other (so-called) independent variables fixed. But what about equations of the type on the right? Every time you attempt to vary the value of one variable to discover its effect on system behavior, you unwittingly “disturb” the values of each of the other variables… which in turn disturbs the variable you’re trying to directly control… which in turn disturbs the set of variables yet again… ad infinitum. It’s called the law of unintended consequences.
Nice and tidy equations of the type on the left are applicable to, and only to, problem modeling in the natural sciences in which the players are time, energy, and mindless chunks of matter. Intractable sets of equations of the type on the right, unsolvable messes in which every variable is correlated which every other variable, are applicable to socio-technical systems where the most influential players have minds of their own. System thinkers focus on the coupling and dynamic interactions between the variables in the system to understand emergent behaviors. Analytical thinkers assume away (either consciously or unconsciously) the nasty, non-linear, inter-variable couplings and thus form an erroneous understanding of the underlying causes of system behavior. Welcome to the guild of business management.
Although I prolly shoulda kept the ingredients secret, here’s my tuna quagmire before the big mix:
And voila, here’s the tuna quagmire after the mix:
Of course, the very best ingredient, by a wide margin, is the BD00 GIANT MARTINI.
The following C++14 code fragment represents a general message layout along with a specific instantiation of that message:
Side note: Why won’t a C++98/03 compiler accept the above code?
Assume that we are “required” to send thousands of these X-Y position messages per second between two computers over a finite bandwidth communication link:
There are many ways we can convert the representation of the message in memory into a serial stream of bytes for transmittal over the communication link, but let’s compare a simple binary representation against an XML equivalent:
The tradeoff is simple: human readability for performance. Even though the XML version is self-describing and readable to a human being, it is 6.5 times larger than the tight, fixed-size, binary format. In addition, the source code required to serialize/deserialize (i.e. marshal/unmarshal) the XML version is computationally denser than the code to implement the same functionality for the fixed-size, binary representation. In the software industry, this tradeoff is affectionately known as “the angle bracket tax” that must be payed for using XML in the critical paths of your system.
If your system requires high rates of throughput and low end-to-end latency for streaming data over a network, you may have no choice but to use a binary format to send/receive messages. After all, what good is it to have human readable messages if the system doesn’t work due to overflowing queues and lost messages?
In his terrific “Effective architecture sketches” slide deck, Simon Brown rightly states that you don’t need UML to sketch up your software architecture. However, if you don’t, you need to consider documenting the documentation:
The utility of using a standard like UML is that you don’t have to spend any time on all the arcane subtleties of meta-documentation. And if you’re choosing to bypass the UML, you’re probably not going to spend much time, if any, doing meta-documentation to clarify your architecture decisions. After all, doing less documentation, let alone writing documentation about the documentation, is why you eschewed UML in the first place.
So, good luck in unambiguously communicating the software architecture to your stakeholders; especially those poor souls who will be trying to build the beast with you.
It seems that several coaches/gurus/consultants/experts use the term “the team” frequently in discussing their work. AS IF there was one, and only one, team: “let the team decide“, “meet the team’s needs“, etc. In complex orgs, there is NOT solely one team. There are many diverse teams and team types. Thus, as expected, their needs can, and do, clash.
To simplify the ensuing, one-way, BD00-to-you discussion, assume the existence of only three different team types:
Just like an individual must sometimes relinquish/suppress a personal need(s) for the greater good of the team, a particular team type must sometimes eschew one or more of its needs for the greater good of a different team type. In darker times, sometimes ALL teams must sacrifice some of their needs for the greater good of the “whole“. After all, if the “whole” goes bust, then all the teams being sustained by it go bust too. In a robust org, the converse is not true: if one team fails, the org will live on.
Is it possible to simultaneously satisfy every single need of each individual, each team, each team type, and the meta-physical “whole“? Since some idealistic people seem to think so, I suppose so – but I’m highly skeptical. The universe has always been, and always will be, gloriously messy. Because of the unavoidable human diversity residing within and across team types, a delicate give-and-take balancing act is necessary to keep the whole intact. Sometimes I gotta give to you and sometimes I gotta take from you. Sometimes you gotta give to me and sometimes you gotta take from me.
Thanks to twitter friend @SerialMom, I recently learned of the existence of Brandolini’s law:
Damn, I wish I thought of that!
Sometimes, in the case of interacting with peers and colleagues, it may indeed be worth expending 100 units of your energy to flush 10 units of bullshit down the terlit. However, with management, don’t even think about refuting 1 unit of managerial-generated BS with 2 units of your intellectual energy – unless you want to get bitch-slapped down. Attempting to refute 100 units of management BS with 1000 units of your personal energy is downright suicidal.