Archive
System Science And Fat Heads
I recently finished reading John Warfield’s An Introduction To System Science . John asserts that whenever you try to design a system that will involve human beings during its operation (and what non-trivial system doesn’t? ), you must take into account these two universal human characteristics:
- The primal instinct to survive
- Miller’s number: 7 plus or minus 2
If your technical system design doesn’t pay homage to these human frailties, it will most likely fail – big time. The money will be gone, the time will be gone, and the damn thing won’t work. Warfield claims that his generic system design process effectively deals with these issues. In his book, John describes his process and cites several examples of it’s success in the public, private, and educational domains.
Warfield also says that the biggest hurdle to overcome, which he doesn’t have a solution for, is the propensity of high level executives for refusing to accept/acknowledge great ideas founded on firm principles from subordinates. I believe what John says, but in my layman’s mind, I equate this strange and unproductive behavior with egomania. The higher up you go and the more titles that you acquire, the bigger and fatter your head gets. Of course, there are always exceptions to every rule :^)
The Beauty Of Quotes Is…
that they are both dense and concise. When I hear a quote that hits close to home it rocks my world like a Mike Tyson power punch (when he was in his prime). Sometimes the effect is positive and sometimes it’s negative, but it’s always impactful. Here’s a top 10 list of my current favorites:
- “Nothing is impossible for the man who doesn’t have to do it himself.” – A. H. Weiler
- “An undefined problem has an infinite number of solutions.” – Robert A. Humphrey
- “A picture is worth a thousand words. A metaphor is worth a thousand pictures.” – Ben Tamari
- “Comprehensiveness is the enemy of comprehensibility.” – Martin Fowler
- “Creation is an intimate act of communication between the creator and the created.” – W. L. Livingston
- “Facts are useful because they give the conscious mind something to do while the emotions decide what’s true” – Dale Dauten
- “I hold great hopes for UML, which seems to offer a way to build products that integrate hardware and software, and that is an intrinsic part of development from design to implementation. But UML will fail if management won’t pay for quite extensive training, or toss the approach when panic reigns.” – Jack Gannsle
- “If I had an hour to save the world, I would spend 59 minutes defining the problem and one minute finding solutions” – Albert Einstein
- “I know that I am intelligent, because I know that I know nothing.” – Socrates
- “It is only by risking our persons from one hour to another that we live at all.” – William James
What’s your current favorite list?
Product Development Systems
The figure below shows two (out of a possibly infinite number of) product development systems. Which one will produce the higher quality, lower cost product in the shortest time? Would a hybrid system be better?

Scary Stuff
Since the word “manager” appears directly in their title, I can certainly understand (and maybe even empathize a little, just a little) why a product manager, program manager, and a general manager would obsess about meeting the schedule. However, it gets real freakin’ scary when all the engineers are talking about schedule too! It makes me think:
If everybody on the project is concentrating on the schedule, who the hell is doing the freakin’ work?
Serendipity
Don’t ya just love serendipity? After hearing the oft-repeated “why does software take so long?” question for the bazillionth time in my career, a fuzzy version of a quote I heard a long time ago came to mind. It was something like “anything is easy for the man who doesn’t have to do it himself”. I fuzzily thought that Mark Twain was the originator of the quote. For at least 20 minutes, I googled “Mark Twain” and various phrasings of the quote in an attempt to try and find the exact version of it. Alas, it was not to be and I moved on with my life.
A couple of days ago, guess what happened? Serendipity came to the rescue via my RSS reader. One of the blogs that I subscribe to is called “Quotes Of the Day”. Sure enough, this showed up as one of them:
“Nothing is impossible for the man who doesn’t have to do it himself.”- A. H. Weiler
Kool huh? I was so thrilled that serendipity paid me a visit that I incorporated the quote into my e-mail signature.
Anti-Collaboration
I’d like to think that most people would agree with me when I make the following assertion:
Dysfunctional corpo orgs that consciously (or unconsciously) maintain a localized lock on knowledge, expertise, and experience steer themselves toward inefficient and mediocre organizational performance.
Thus, it pains me when I come across (so-called) leaders who ignore social collaboration tools that could bust the chastity belt lock wide open and tremendously boost corpo performance. Believe it or not, some managers go beyond the call of duty. Because of their innate fear of change and their instinctual desire to maintain the status quo, they discourage the use of these tools by never using them to contribute and by privately ostracizing the people that are trying to use them for the company’s benefit. Yet, they always seem to be going to meetings where cost reduction and productivity improvements are the burning fires of the day. What a wonderful world :^)
Arrogant And Self-Righteous
I’m currently working on a really difficult assignment that’s starting to put me into an arrogant and self-righteous mood. My task is to add a customer-demanded feature to our flagship product that requires pervasive change throughout 400,000 lines of legacy embedded C++ code. Our flagship product is a software-intensive, distributed real-time sensor system that’s used to provide safety-critical surveillance information to our customers.

This is actually the third try at getting this task done. The first two attempts by other people fizzled out with nary a whimper. They were in way over their heads and thus, the work that they left behind is useless to me. So here I am, reverse-engineering 100s of thousands of lines of algorithmically deep code to:
- try and figure out what the current code base does
- try and understand why the code does what it does
- determine what changes need to be made to which code sections in order to implement the feature
This task is hard, really hard, but I’m up to it. The work requires long periods of sustained immersion in the code base and the mental absorption and retention of many fragile and diverse associations. Way more than Miller’s famous 7 plus or minus 2 limit of individual human capacity. I’m not getting any deep help and I’ve got two (yes two) managers taking “status” and watching the schedule . Other well-meaning product team members do help out when I ask them, but they just provide tidbits of help here and there. Help from the managers? Fuggedaboud it. It’s not their “job”, and they don’t have the expertise to help out even if they wanted to (which they don’t). Don’t get me wrong. They’re both good people and I like them very much, but they just can’t help, period.
Alas, I feel that I’m virtually all alone on this effort and it’s making me arrogant, self-righteous, and mad. Why’s it making me mad? Because I don’t feel appreciated and I feel that no one, save for one other person, has any idea of the inherent difficulty baked into the project. I look at what I’m doing, compare it with what others around me are doing, and then I ask myself “why did I willingly sign up for this type of work – again“? When the job gets finished, I’ll in all likelihood just get an “atta boy” and the same average raise as everyone else – just as has happened several times in the past. Thank God that I’m internally motivated to grow and learn.
Boo hoo, poor me!
Sassy!

The SAS Institute has been one of my favorite software companies to watch over the years. They were like Google before Google. The reason that I’m mentioning SAS is because while I was browsing through my notes, I stumbled upon this quote from a SAS manager:
Nothing corrodes respect between a boss and an employee more quickly than the sense that the boss has no idea what the employee is doing. Managers who understand the work that they oversee can make sure that details don’t slide. At SAS, groups agree on deadlines, and managers understand what their groups do — so unrealistically optimistic promises about time-tables and completion dates are relatively rare.
The quote came from this 2004 article in Fast Company magazine: Sanity Inc. The quote struck a chord with me back then, and it still does now. In my case, I don’t necessarily disrespect a manager that doesn’t know what I’m doing. I disrespect managers who:
- Are apathetic and show no interest in what I’m doing, regardless of whether they know the subject matter or not.
- Don’t ask me how I’m doing, and how they can help me do my job better, regardless of whether they know the subject matter or not.
- Just stop by only when they need to collect status, without wanting to hear about any bureaucratic procedural roadblocks that are, or specific people who are, hindering my progress.
- Pretend to know what I’m doing and make suggestions on what to do next, even though we both know (or, at least I know) that the manager has no clue.
How about you? What causes you to lose respect for your manager(s)?
A Metafesto
Being a software engineer, I’m always on the hunt for better ways to develop software. In my continuous search for excellence, I’ve recently been bombarded by what seems like an endless stream of manifestos. Here are some of the most “famous” ones:
They’re all so brilliantly elegant and moving that I want to put them on little magnets and display them in my cube right next to the company core values and quality policy magnets.
In response to the manifesto craze, I’ve come up with my own “metafesto”. A manifesto about manifestos.
Enough already! Stop talking about manifesting some ideal behavior and just do it. Manifest what you wrote yourself. No need to get up on a soapbox and pontificate to the masses of little people so that they do things the “right” way. If what you preach works, and people see it and resonate with it, then they’ll manifest what you’re manifesting. I hereby renounce all software-oriented manifestos as self-righteous and dictatorial rules wrapped in elegant and poetic rhetoric.
Do as Ghandi says: ““We must become the change we want to see.” He didn’t say “Talk about the change we want to see” in the world.
Analysis Vs. Synthesis
Everybody’s an expert analyzer. We slice, we dice, we evaluate and judge everything and everyone around us. “That’s good, that’s bad, you should’ve done it this way”, yada, yada, yada. Analysis is easy, but how many of us are synthesizers and/or integrators, CREATORS?
The problem is that we’re taught to analyze and critique from day one. We start with our parents and we are continually reinforced over time by our education system until we’re rigid adults who know how “things should be”. Over and over, we’re presented with something that already IS (like a circuit drawing, a business case, an a-posteriori historic event) , and we are taught how to criticize it and how to vocalize that “it should have been done this way”.
That’s too bad, because we are all born with the innate ability to be synthesizers, integrators, or in summary, CREATORS. We were born of creation, and thus we are creators. Sadly, we lose touch of that simple fact of life because of our inculcated obsessive infatuation with academic intelligence and the ego-driven desire to know more than “others”. Our western societies reward and glorify left brain “experts” and they shun, or even ridicule, wild-ass innovators and creators (at least until aftet they’ve died). Creators and innovators are often ostracized by the herd because they shatter the status quo and disorient us from the comfort of our lazy Barca-loungers.
The figure below shows the difference between analysis and synthesis (Cx = component x). In the analysis scenario, we are given something that exists and then we are asked to evaluate it, to determine what’s good/bad about it, and to develop ideas on how to improve upon it. In school, we are taught all kinds of discipline-specific techniques and methods for decomposing and breaking things down into parts so that we can improve upon the existing design. But analyzing the parts separated from the whole doesn’t get us anywhere because the whole includes and transcends the individual parts. By breaking the system apart we obliterate the essence of the system, which is the magic that exists in the interactions between its parts. Blech! Meh! Hawk-tooey!

The synthesis scenario is downright scary. We are given a novel problem, a bounded set of parts (if we’re lucky), and told to “come up with a solution” by the boss. Dooh! Uh, I don’t know how to do that cuz I wasn’t taught that in school. I think I’ll bury my head in the sand and hope that someone else will solve the problem.
Synthesis transcends and includes analysis. You can’t be a good synthesizer without being a good analyzer. You synthesize an initial solution out of intellectual “parts” known to YOU and then you analyze the result. If you aren’t familiar with the problem domain, then you have no “parts” in your repository and you can’t come up with any initial solution candidates. End of story. If you do have experience and knowledge in the problem domain, then you can synthesize an initial solution. You can then iterate upon it, replace bad parts with better parts, and converge on a “good enough” solution without falling into an endless analysis-paralysis loop. During the process of synthesis, you dynamically rearrange structures, envision system behavior, and iterate again until it “intuitively feels right”. All this activity occurs naturally, chaotically, at the speed of thought, and to the chagrin of the masses of Harvard trained MBAs, in no premeditated or preplanned manner.
Ultimately, in order to share your creative results with others, you must expose your baby for “analysis”. Now THAT, is the hard part. For most people, it’s so hard to expose their creations to ridicule and humiliation that they keep their creations to themselves for fear of annihilation by the herd of analyzers standing on the sideline ready to attack and criticize. It sux to be a synthesizer, and that’s why the vast majority of people, even though every one of them is innately capable of synthesizing, fail to live fulfilling lives. Bummer!
