Archive
Disconnected DICs
Without continuous, sincere, hard work from the leadership in a CCH (Command and Control Hierarchy) structure of human organization, it is all but guaranteed that the communication gap size between adjacent layers will exponentially increase when one traverses from the top level down to the bottom level.
The communication gap between two non-adjacent levels is even wider, culminating with a gap size of infinity between the DICs at Level=0 and the corpo hierarchs at Level=MAX. Bummer.
Architectural, Mechanistic, And Detailed
Bruce Powel Douglass is one of my favorite embedded systems development mentors. One of his ideas is to categorize the activity of design into three levels of increasingly detailed abstraction:
- Architectural (5 views)
- Mechanistic
- Detailed
The SysML figure below tries to depict the conceptual differences between these levels. (Even if you don’t know the SysML, can you at least viscerally understand the essence of what the drawings are attempting to communicate?)
Since the size, algorithmic density, and safety critical nature of the software intensive systems that I’ve helped to develop require what the agile community mocks as BDUF (Big Design Up Front), I’ve always communicated my “BDUF” designs in terms of the first and third abstractions. Thus, the mechanistic design category is sort of new to me. I like this category because it shortens the gulf of understanding between the architectural and the detailed design levels of abstraction. According to Mr. Douglass, “mechanistic design” is the act of optimizing a system at the level of an individual collaboration ( a set of UML classes or SysML blocks working closely together to realize a single use case). From now on, I’m gonna follow his three tier taxonomy in communicating future designs, but only when it’s warranted, of course (I’m not a religious zealot for or against any method), .
BTW, if you don’t do BDUF, you might get CUDO (Crappy and Unmaintanable Design Out back). Notice that I said “might” and not “will”.
Weasel Words
According to one or more of the authorities of Wikipedia, “the purpose of an encyclopedia is to spread accurate and useful information. Weasel words are imprecise, often inaccurate, and usually uninformative.” Note that the phrases “often inaccurate” and “usually uninformative” in the previous sentence are weasel words that describe weasel words.
Since this blog, and most others (<— more weasel words), aren’t meant to be encyclopedias, I knowingly and purposefully use weasel words all the time. Like everything else in the world, weasel words are neither good nor bad, they just are.
Oh Goody, A New Discovery
It’s funny how virtually every person has the tendency to constantly seek out references that confirm and validate his/her “beliefs”, while at the same time ignoring evidence to the contrary – no matter how strong the disconfirming evidence is. As a member of this non-exclusive club myself, the latest self-medicating anti-hierarchy book that I’m reading is called “The Age Of Heretics: A History of the Radical Thinkers Who Reinvented Corporate Management“. The content on changing corporate governance is interesting, but the multiple references to spiritual teacher and mystic G. I. Gurdjieff are what really kindle my curiosity.
Over the past 10+ years, I’ve read the works of many well known spiritual teachers in an attempt to counter my tendency to rely solely on a logical and mechanistic engineering mindset to travel through life. Since Gurdjieff is new to me, I’m gonna look into his work. Thus, the next book in my reading queue is titled Gurdjieff.
.
The Wall
The figure below shows the financial performance of a successful hypothetical company. During the startup phase, both revenue and profit increased at a linear pace, and then something interesting happened. As revenue rose, profit growth hit a wall and leveled off. Dooh!
So, what happened? In business lingo, the costs to execute the business rose faster than the costs to acquire the revenue. Since we are not company insiders, we can only speculate as to the underlying cause(s) of the performance slip, but here are two out of a bazillion possibilities:
- More bureaucrats were added at a faster rate than people with the skills and ability to execute.
- The company’s execution processes were unscaleable.
Let’s explore these two performance busters.
More bureaucrats were added at a faster rate than people with the skills and ability to execute.
With revenue pouring in, it’s easy to become sloppy and careless with all that dough. Egotistical managers, unconsciously trying to outdo one another by building personal empires, convince their disconnected and aloof next-level managers that they need more people for business execution, regardless of whether they actually do need them. These new additions are often specialists who are only capable of executing narrow slivers of the business. Thus, they spend most of their time in idle mode; consuming more from the company than they contribute.
On the other hand, the new additions may be ambitious, unskilled fellow managers who are tasked with doing what their bosses couldn’t – increase execution performance with the people that they currently have. By adding more sub-managers, each super-manager builds his/her empire and further buffers him/herself from where the rubber hits the road in the execution trenches.
The company’s execution processes were unscaleable.
Unless the company produces widgets or some other simple product that doesn’t require knowledge synthesis and frequent human situational decision-making skills, its business execution processes may be unscaleable. In a sincere but misguided attempt to control and increase execution performance, the company’s managers actually decrease scaleability and they inhibit performance gains by piling more constraining rules and procedures on top of the people who create, manufacture, test, and sustain the product portfolio. Rather than rolling up their sleeves and jumping in with their people to help them get the job done, these managers spend all of their time running around taking status and ensuring that all the rules and procedures are followed.
Can you think of any other reasons why this successful company may have stumbled?
All in all you’re just another brick in the wall. – Pink Floyd
SysML Diagram Headers
The Systems Modeling Language, SysML, is both an extension and a subset of the UML. SysML defines a “frame” that serves as the context for a given diagram’s content. As the diagram below shows, each frame contains a header compartment that houses 4 text elements which characterize the diagram. The two items in brackets are optional.
While learning the SysML, I was often confused as to the order of the header items and their meanings. My first thought when I saw the frame header was; “why are there so many freakin’ header entries; why not just one or two?”. I still get confused, but after studying a bunch of sample diagrams from System Engineering With SysML/UML: Modeling, Analysis, Design and A Practical Guide to SysMLThe Systems Modeling Language, I think that I have almost figured it out.
With the aid of the two previously mentioned references, I constructed the table below. There are 9 enumerated SysML diagrams, so understanding what the “diagram kind” header field means is trivial. It’s the optional “model element” header item that continues to confuse me. As you can see from the table, the types of “model element(s)” that can appear within the first 6 diagrams are fixed and finite. However, the last three are open ended.
The problem for me is determining what the set of all “model element types” is. Is it a finite set of enumerations like the “diagram kind” header entry, or is it free form and ad-hoc? Does anyone know what the answer is?
Software Developer Revolt!
As the size and complexity of the software-intensive systems that we need to develop increase, a corresponding rise in the level of abstraction of the programming languages used to build them has understandably increased. From routines to functions, to objects, to namespaces, the progression in abstract text-based language encapsulation mechanisms is depicted in the figure below. Will the transition from text-based languages to graphics-based languages infiltrate the mainstream soon? Isn’t it inevitable that graphical languages, and the tools that enable their use, will push the art of hand-coding via text languages into the dust bin of irrelevance?
In his book Real-Time Agility: The Harmony/ESW Method For Real-Time And Embedded Systems Development, Bruce Powel Douglass unabashedly says “YES!”. His agile methodology (yes, yet another “agile” methodology is foisted upon us) doesn’t even require a “coding” phase/activity.
The figure below attempts to contrast the mainstream CDD (Code Driven Development) approach of today with an MDD (Model Driven Development) approach like Mr. Douglass’s. Will the transition from one dimensional text-based languages to more abstract, two dimensional graphics-based languages be too much of a leap for today’s programmers? Compared with text-to-text language transitions, a text-to-graphics language jump is more akin to a disruptive quantum leap. Will software developers ironically morph into Luddites, fighting this technological change tooth and nail? Is the UML today’s graphical incarnation of the text-based assembler language of yesterday? Will tools like IBM’s Rhapsody and Artisan’s Studio supplant the myriad of compiler-linker toolchains of today? What say you?
Learn A Little, Do A Lot
There is no “learn” in “do” – manager yoda
Assume that you have a basic skill set, some expertise, and some experience in a domain where a task needs to be performed to solve a problem. Now assume that your boss assigns that problem to you and, out of curiosity you decide to track how you go about solving the problem.
The figure below shows the likely result of tracking your problem solving effort. You probably converged on the solution via a series of continuous Learning-Doing iterations. On your first iteration, you gathered a bunch of information and spent a considerable amount of time immersing yourself in the problem area to “learn” both context and content. Then you “did” a little, producing some type of work output – which was wrong. Next, you spent some more time “learning” by analyzing your output for errors/mistakes and correlating your work against the information pile that you amassed. Then you repeated the cycle, doing more while having to learn less on each subsequent iteration until voila, the problem was solved!
So, how can this natural problem solving process get hosed and low quality, shoddy work outputs be produced? Here are three possible reasons:
- Lack of availability of, or accessibility to, applicable information.
- Low quality, inconsistent, and ambiguous information about the problem.
- Explicit or implicit pressure to abandon the natural and iterative Learn-then-Do problem solving process.
IMHO, it should be a manager’s top priority to remove these obstacles to success. If a manager ignores, or can’t fulfill, this critical responsibility and he/she is just an obsessive, textbook-trained “status taker and schedule jockey”, then his/her team will transform into a group of low quality performers. More importantly, he/she will lose the respect of those team members who deeply care about quality.
What Happened To Ross?
In the ideal case, an effectively led company increases both revenues and profits as it grows. The acquisition of business opportunities grows the revenues, and the execution of the acquired business grows the profits. It is as simple as that (I think?).
ROS (Return On Sales) is a common measure of profitability. It’s the amount of profit (or loss) that remains when the cost to execute some acquired business is subtracted from the revenue generated by the business. ROS is expressed as a percentage of revenue and the change in ROS over time is one indicator of a company’s efficiency.
The figure below shows the financial performance of a hypothetical company over a 10 year time frame. In this example, revenues grew 100% each year and the ROS was skillfully maintained at 50% throughout the 10 year period of performance. Steady maintenance of the ROS is “skillful” because as a company grows, more cost-incurring bureaucrats and narrow-skilled specialists tend to get added to manage the growing revenue stream (or to build self-serving empires of importance that take more from the org than they contribute?).
For comparison, the figure below shows the performance of a poorly led company over a 10 year operating period. In this case the company started out with a stellar 50% ROS, but it deteriorated by 10% each subsequent year. Bummer.
So, what happened to ROS? Who was asleep at the wheel? Uh, the executive leadership of course. Execution performance suffered for one or (more likely) many reasons. No, or ineffective, actions like:
- failing to continuously train the workforce to keep them current and to teach them how to be more productive,
- remaining stationary and inactive when development and production workers communicated ground-zero execution problems,
- standing on the sidelines as newly added “important ” bureaucrats and managers piled on more and more rules, procedures, and process constraints (of dubious added-value) in order to maintain an illusion of control,
- hiring more and more narrow and vertically skilled specialists that increased the bucket brigade delays between transforming raw inputs into value-added outputs,
may have been the cause for the poor performance. Then again, maybe not. What other and different reasons can you conjure up for explaining the poor execution performance of the company?
The Vault Of No Return
In big system development projects, continuous iteration and high speed error removal are critical to the creation of high quality products. Thus, it’s essential to install flexible and responsive Configuration Management and Quality Assurance (CMQA) support systems that provide easy access to intermediate work products that (most definitely) will require rework as a result of ongoing learning and new knowledge acquisition.
As opposed to virtually all methodologies that exhort early involvement of the CMQA folks in projects, I (but who the hell am I?) advise you to consider otherwise. If you have the power (and sadly, most people don’t), then keep the corpo CMQA orgs out of your knickers until the project enters the production phase. Why? Because I assert that most big company CMQA orgs innocently think they are the ends, and not a means. Thus, in order to project an illusion of importance, the org creates and enforces Draconian, Rube Goldberg-like, high latency, low value-added, schedule-busting procedures for storing work products in the vault of no return. Once project work products are locked in the vault, the amount of effort and time to retrieve them for error correction and disambiguation is so demoralizing and frustrating that most well-meaning information creators just give up. Sadly, instead of change management, most CMQA orgs unconsciously practice change prevention.
The figure below contrasts two different product developments in terms of when a CMQA org gets intertwined with the value creation project pipeline. The top half shows early coupling and the bottom half shows late coupling. Since upstream work products are used by downstream workgroups to produce the next stage’s outputs, the downstreamers will discover all kinds of errors of commission and (worse,) omission. However, since the project info has been locked in the vault of no return, if the culture isn’t one of infallible machismo, upstream producers and downstream consumers will circumvent the “system” and collaborate behind the scenes to fix mistakes and clarify ambiguities to increase quality. If and when that does happen, the low quality, vault-locked information gets out of synch with the informal and high quality information in the pipeline. Even though that situation is better than having both the vault and project pipeline filled with error infested information, post-delivery product maintenance teams will encounter outdated and incorrect blueprints when they retrieve the “formal” blueprints from the vault. Bummer.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 