Archive
Not Baffling
“Increasingly, people seem to misinterpret complexity as sophistication, which is baffling—the incomprehensible should cause suspicion rather than admiration. Possibly this trend results from a mistaken belief that using a somewhat mysterious device confers an aura of power on the user.” – Niklaus Wirth
Niklaus, it’s not baffling. People do it because, in a society that adores academic intelligence over all else, they don’t want to look and feel stupid in front of others. By acting as though they admire an incomprehensible monstrosity that they don’t understand, the people around them (especially the creators of the untenable complexity) will think they are smart and sophisticated too.
Regardless of whether the “misinterpretation” happens consciously or unconsciously, it’s ego driven. I know this because I’ve done it many times…….. both consciously and unconsciously.
“The intuitive mind is a sacred gift and the rational mind is a faithful servant. We have created a society that honors the servant and has forgotten the gift.” – Albert Einstein
The Best Defense
In “The Design Of Design“, Fred Brooks states:
The best defense against requirements creep is schedule urgency.
Unfortunately, “schedule urgency” is also the best defense against building a high quality and enduring system. Corners get cut, algorithm vetting is skipped, in-situ documentation is eschewed, alternative designs aren’t investigated, and mistakes get conveniently overlooked.
Yes, “schedule urgency” is indeed a powerful weapon. Wield it carefully, lest you impale yourself.
High And Low Tides
I’m lucky to have a job with variety. Most of the time, I’m either specifying, designing, writing, documenting, or fixing software that enhances or keeps our product portfolio viable. However, not all project work is equi-important to the company’s prosperity.
Some of the projects that I work on are bland, menial, and they don’t contribute much to the development of my company. When I work on these types of projects, I tend to feel guilty, overpaid, and like an under-performer. Accordingly, my behavior changes to align with those feelings. I turn inward, I’ m less interactive with others, and I’m less likely to observe, sense, and provide “controversial” input on socio-technical issues that I perceive to be holding the company back.
On the other side of the coin, when I work on challenging and intense work that I perceive is propelling the company forward, I gravitate towards ego-centric feelings of arrogance and superiority. I feel underpaid, under-appreciated, and overworked (boo hoo!). I become a “legend in my own mind“.
In either mode of behavior, it’s real easy to lose perspective and alienate co-workers and leaders. The key to balanced behavior during these high and low tides, which I haven’t yet figured out how to turn, is to recognize when I’m deep into one mode or the other.
How about you? Do you oscillate between extremes? Do you continuously dwell in one of the extreme states? Are you always Buddha-centered? If so, how do you know you are?
Expected Forgetfulness
BMs and CCRATs in mediocracies always require that the DIC-force conveniently forget the parade of reorgs and resource draining initiatives that they have started but have never followed through on over the years. However, they’ll be the first to remind project contributors when they “haven’t met schedule” or when their project came in “over budget“.
DIC-sters, either consciously out of fear or unconsciously from years of mind-numbing indoctrination, comply dutifully with the “expected forgetfulness” rule in order to preserve the mediocre performance that gives a mediocracy is meaning. All attempts to point out the blatantly obvious but undiscussable hippocracy of CCRAT demands for schedule and cost compliance, while simultaneously underperforming in these areas themselves, is met with swift retribution. This happens even in the extremely rare cases when a hierarch himself loses his sanity for a nanosecond and tries to right the wrong.
Services And Outcomes
In an e-mail from friend and mentor Bill Livingston, he said:
If duty is focused on method and practices, there can be no responsibility either for meeting the objective or for any consequences of services. If goal attainment is chosen paramount, there can be no limitations on methodology. Duty for professional services is given by authority. Responsibility for outcomes must be willingly taken by the designer. – William L. Livingston
Think about how obsessed most companies (especially large ones run by fat heads) are with regard to following standard corpo policies, rules, methods, and practices. In other words, red freakin’ tape. In these abominations that have lost their way, if one is a good soldier and loyally follows the unchangeable rules inscribed in stone by the dudes in the head shed, there can be no repercussions for failure to achieve goals. After all, since the corpocrats created the operational rule set and they’re (of course) infallible, that means the rule set is perfect. Hence, if you follow the rules to the letter but cause a disaster, you’re absolved.
Unconstrained To Constrain
As I continue to slowly inhale Fred Brooks‘s book, “The Design Of Design“, I’m giddily uncovering all kinds of diamonds in the rough. Fred states:
“If designers use a structured annotation or software tool during design it will restrict the ease of having vague ideas, impeding conceptual design.”
Ain’t that the truth? Don’t those handcuffing “standard document templates, processes, procedures, work instructions” that you’re required to follow to ensure quality (lol!) frustratingly constrain you from doing your best work?
Along the same lines, Fred hits another home run in my ballpark (which is devoid of adoring and paying fans, of course):
“I believe that a generic diagramming tool, with features such as automatic layout of trees, automatic rerouting of relationship arrows, and searchable nodes, is better suited to (design) tree capture. Microsoft Visio or SmartDraw might be such a choice.”
Man, this one almost made me faint and lose consciousness. I live, eat, and breath “Visio”. Every picture that you’ve seen in this blog and every design effort that I undertake at work starts with, and ends with, Visio – which is the greatest tool of expression I’ve ever used. I’ve tried “handcuffers” like Artisan Studio and Enterprise Architect as software design aids, but they were too frustratingly complex and constraining to allow me to conjure up self-satisfying designs.
All designs must eventually be constrained so that they can be built and exploited for profit. But in order to constrain, one must be unconstrained. How’s that for a zen-like paradox?
Leverage Point
In this terrific systems article pointed out to me by Byron Davies, Donella Meadows states:
Physical structure is crucial in a system, but the leverage point is in proper design in the first place. After the structure is built, the leverage is in understanding its limitations and bottlenecks and refraining from fluctuations or expansions that strain its capacity.
The first sentence doesn’t tell me anything new, but the second one does. Many systems, especially big software systems foisted upon maintenance teams after they’re hatched to the customer, are not thoroughly understood by many, if any, of the original members of the development team. Upon release, the system “works” (and it may be stable). Hurray!
In the post delivery phase, as the (always) unheralded maintenance team starts adding new features without understanding the system’s limitations and bottlenecks, the structural and behavioral integrity of the beast starts surely degrading over time. Scarily, the rate of degradation is not constant; it’s more akin to an exponential trajectory. It doesn’t matter how pristine the original design is, it will undoubtedly start it’s march toward becoming an unlovable “big ball of mud“.
So, how can one slow the rate of degradation in the integrity of a big system that will continuously be modified throughout its future lifetime? The answer is nothing profound and doesn’t require highly skilled specialists or consultants. It’s called PAYGO.
In the PAYGO process, a set of lightweight but understandable and useful multi-level information artifacts that record the essence of the system are developed and co-evolved with the system software. They must be lightweight so that they are easily constructable, navigable, and accessible. They must be useful or post-delivery builders won’t employ them as guidance and they’ll plow ahead without understanding the global ramifications of their local changes. They must be multi-level so that different stakeholder group types, not just builders, can understand them. They must be co-evolved so that they stay in synch with the real system and they don’t devolve into an incorrect and useless heap of misguidance. Challenging, no?
Of course, if builders, and especially front line managers, don’t know how to, or don’t care to, follow a PAYGO-like process, then they deserve what they get. D’oh!
Waiting For Management Guidance
In “The Design Of Design“, Fred Brooks laments that he used to be able to track new developments in the entire field of software engineering – which was born in 1968. In the present age, because of massive innovation, expansion, and deep specialization requiring steep learning curves, he realizes that there’s no hope of anyone being super human enough to keep up anymore.
Since I used to try to keep abreast of all developments in the field, I felt the same way as Fred. Now, I have a strategy that keeps me from staying awake 24×7 reading books, papers, newsletters, blogs, and articles. I filter the tsunami of information down by trying to track developments only in my domain of focus; distributed and embedded real-time systems. I occasionally look into the fast moving enterprise IT technology space for cross-domain applicability of ideas, but it’s all I can do to keep abreast of my area while simultaneously doing some real application work that adds value to my company‘s products.
How about you? Do you find yourself overwhelmed by the rate and amount of information being created and disseminated in your field? Do you care about and pursue personal exploration and discovery, or do you just punch the clock and wait for the infallible geniuses in management to guide and train you in the new technologies that could keep you and your org viable? If it’s the latter, then you may (as the left portion of the figure below shows) remain stuck in the stagnant and boring “Waiting For Management Guidance” state forever. If you’re dwelling in this sad and potentially infinite state, there is still hope in the form of an “epiphany” of understanding – big daddy ain’t gonna help you grow personally or professionally.
Ideally, one never wastes any time in the spirit-sucking “Waiting For Management Guidance” state. The “Exploring And Discovering” state, which is a natural gift to all human beings, would be transitioned to right out of the box. When we are born, we actually do enter this state right out of the box – so to speak. As soon as we start going to school, the institutional indoctrination starts and before we can say WTF?, we’re well on our way to the “Waiting For Management Guidance” state.
The Answer To A Burning Question
Ever since Fred Brooks hatched his legendary “The Mythical Man Month” over 20 years ago, he’s been on my hero/mentor list. His latest insightful work, “The Design Of Design“, is just as good as TMMM. Of course, since my views on software engineering (if it can be called engineering) are heavily influenced by his experiences as shared through his writing, I’m totally biased and unobjective (but….. aren’t we all to some extent?).
I pre-ordered TDOD as soon as I heard about its impending release and I received it from Amazon last week. Unlike most books, which I mildly speed read, I’ve been savoring this one slowly. As expected, I’ve been discovering and extracting a treasure trove of personally valuable fieldstones from TDOD at a feverish pace.
Fred opens up one of his chapters with this brilliant quote:
“A meeting is a refuge from the dreariness of labor and the loneliness of thought.” – Bernard Baruch
I think it’s brilliant because it answers a burning question that I haven’t been able to self-answer for a long time in one short sentence:
Why do managers spend the vast majority of their time in meetings?
Thanks to Fred and Bernie, I now know why 🙂
Conceptual Integrity
Like in his previous work, “The Mythical Man Month“, in “The Design Of Design“, Fred Brooks remains steadfast to the assertion that creating and maintaining “conceptual integrity” is the key to successful and enduring designs. Being a long time believer in this tenet, I’ve always been baffled by the success of Linux under the free-for-all open source model of software development. With thousands of people making changes and additions, even under Linus Torvalds benevolent dictatorship, how in the world could the product’s conceptual integrity defy the second law of thermodynamics under the onslaught of such a chaotic development process?
Fred comes through with the answers:
- A unifying functional specification is in place: UNIX.
- An overall design structure, initially created by Torvalds, exists.
- The builders are also the users – there are no middlemen to screw up requirements interpretation between the users and builders.
If you extend the reasoning of number 3, it aligns with why most of the open source successes are tools used by software developers and not applications used by the average person. Some applications have achieved moderate success, but not on the scale of Linux and other application development tools.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 