Archive
System Architecture Notation
For years and years, I’ve used the simple circle and square notation shown in the top half of the figure below in order to communicate (mostly to myself) multi-technology system designs. I did it because UML hadn’t been invented yet, and circles/squares were trivial to draw with any software drawing tool.
Now that UML has been out for quite a while, I’m gonna (try) and switch to the UML notation shown in the bottom half of the diagram. Even though packages and nodes are slightly harder to draw than circles and squares with most mainstream drawing tools, every UML tool makes it as easy as pie. Even Visio (my favorite engineering graphics tool) has templates for easily generating UML notation.

Contained And Container
In Russell Ackoff‘s excellent book titled Idealized Design , he talks about container and contained systems. He essentially states that optimizing the contained system without changing the container system is a failure in waiting. The figure below depicts what often happens when a change agent succeeds in improving the contained system without consideration of the container system.

At time 1, the change agent realizes that there is an efficiency problem within the contained system. After an epic battle against the forces conspiring to keep the status quo intact, he/she succeeds in smoothing out the operation of the contained system at time 2. However, since the container system was neglected, it still operates according to the old rules and interfaces of time 1. Thus, an impedance mismatch between the container and contained system interface has appeared. This impedance mismatch can cause organizational performance to be worse than before the change (the cure is worse than the disease) to the contained system!
In an ideal system change effort, both the container and contained systems are improved. Done correctly, a smooth and high performing system-of-systems, like the above model at time 3, can be achieved. Compare the smooth circular integrated interface at time 3 with the previous inefficient and cloudy interfaces of the previous 2 times.
The Single Most Important Thing
Scott Berkun is one of my favorite technical consultants. He’s a former Microsoft program manager who worked on the development of Internet Explorer and he’s written two classic books on project management and innovation. In this post: power, Scott states a simple and profound truth:
As a program manager (glorified title for project manager), all of my power actually came from the programmers. I only had a job because of the programmers. No programmers means no code, no product, no revenue. End of story. My power was an extension of theirs. I had to treat them with respect and go out of my way to earn their trust over time.
I’d like to extend Scott’s opening sentence so that it applies to companies that develop multiple-technology products containing an integrated system of software, digital hardware, mechanical hardware, and electrical hardware.
As a program manager (glorified title for project manager), all of my power actually came from the engineering groups….. I had to treat them with respect and go out of my way to earn their trust over time.
In multi-technology companies where managers put other peer and higher up managers first, the odds are that schedule, cost, and quality will suffer. Instead of operating like high performing meritocracies, these companies end up just like the rest of the herd; as mediocracies.
Under Siege
Working on a product that requires a multi-disciplined engineering team can be a fun and exhilarating growth experience. However, the fun can be snuffed out by poor management of negative external forces. The figure below shows just some of the forces that can derail a project.

Help!
By far, the pressure exerted by the management chain can cause the most harm to the product and development team. In some companies, the lower level managers are zero resistance conductors of schedule pressure exerted by the higher ups. The negative effects of this pressure are absorbed directly by the development team.
Since I think that all people in an organization are always trying to do the right thing, the reason that this operational behavior is so ubiquitous is that the perps aren’t aware of what they’re doing. In mindful organizations that are aware, the management chain instills a mild and tempered sense of urgency that increases performance without causing harm.
Decision Making Stalemate
Joel Spolsky is one of my favorite software philosophers. Joel sticks to fundamental principles no matter what the latest flavor of snake oil is being preached at the moment.
In this blog post, Endless Debate, Joel states:
“A terribly common error is having a debate over how something should be designed, and then never resolving the debate“.
He follows that with:
“In too many programming organizations, every time there’s a design debate, nobody ever manages to make a decision, usually for political reasons. So the programmers only work on uncontroversial stuff. As time goes on, all the hard decisions are pushed to the end. These are the most likely projects to fail.”
In addition to political reasons, I’d also like to add fear. In alpha male dominated corpo cultures, fear drives the non-alpha members of the group. The titled alphas (a.k.a. managers) rule the roost and the non-alphas go silent when an alpha asserts himself – even if the alpha hasn’t got a clue on what the right course of action is.

Yes Master!
I don’t agree with Joel’s assertion that “all decisions are pushed to the end”. Because of schedule pressure and the fear of reprisal if the alpha’s instructions aren’t followed, the programmer(s) quietly implement the alpha’s horrendous decision in either code, design, or architecture.
The downstream ramifications of implementing the wrong decision get worse depending at which level of abstraction they are manifest. When the customer: gets the software, discovers the problem, and demands that it be fixed, the alphas are quick to blame the programmers since it’s often impossible, or not politically correct, to trace the problem back to it’s root cause – the bozo alpha’s poor technical decision.
Who said that life was fair?
Filtering And Distortion
Virtually everyone sees “life” as an integrated, filtered, and distorted stream of continuous analog input. Each filter is person-specific and tends to get narrower as we supposedly grow-up. The designer of the filter is the personal ego and if you’re not aware of this, it can severely degrade and limit your experience of life. My goal is to remove my personal filter so that I can experience the glorious full spectrum of life. I may not attain this goal, but I’m going to try to achieve it until my last breath. Please wish me luck.

Spiritual Teachers
For many moons, I’ve been educating myself on the topic of spiritual growth in order to become a better person and experience more peace in my life. Here are my teachers (so far).

Human And Professional Respect
Maybe I shouldn’t, but I quantize respect into two simple categories: human and professional. I respect every person who walks the face of the earth as a human being. We’re all just trying to do our best to find our path through life.
Professional respect is another story. Unlike human respect, I don’t auto-give it to anyone because I think it must be earned. I’m really turned off by people who think they are entitled to respect because they’ve been granted a title by someone with a bigger and more grandiose title. Historically, titles have been predominantly used to create the illusion that “I’m better than you”. Thus, they’re a huge turnoff for me.
Until you prove yourself worthy of some “lofty” title by helping people to grow and succeed, you’re not worthy of professional respect from me. I’ve developed this titular attitude after having experienced lots of “professionally unrespectful” people cross my path over the years.
Meditation Failure
Over the years, I’ve progressively transitioned between these stances on meditation: 1) It’s a waste of time, 2) It may have merit, 3) It DOES have merit, 4) It’s too frustratingly hard for me.
During the leap from state 3) to 4), I gave meditation a half-assed try. I read a bunch of material on the topic. Most of it recommended meditating for as long as you can – up to 12 hours a day (WTF!!!). Much of it also said that it can take years to get really proficient at it.
Over the past few months, I’ve tried to meditate every night just before going to sleep even though the literature says not to meditate if you’re sleepy (I told you I was trying it half-assed). I use my breath as the meditation object. It just doesn’t work for me. As soon as I focus my concentration on my breath, within a microsecond a thought invades and I’m off to the races with it for a few seconds. I attach to it, and follow it fully along with the numerous child thoughts that it spawns. Then, for a reason that I don’t understand, I “suddenly” realize that I’ve been hoodwinked by my thought-obssessed ego again and I try to refocus on my breath. Sure enough, within a picoseond another thought zooms in and I repeat the cycle. Frustration reigns.
All the literature that I’ve read says to be patient and gentle with yourself and don’t get discouraged when you find yourself being drawn into thoughts that instantaneously arise during meditation. Easier said than done.
Ego Battles!

Ego battles are the psychological equivalent of physical altercations. While we might not often experience physical altercations, most of us participate in ego battles on a daily basis. Unconscious, arrogant and/or smug people are constantly battling with others to show them “who’s right”. The so-called winner may feel better at the expense of the loser(s), but it’s only a temporary high. I know this to be true because I unconsciously don my armor every morning.
