Archive
Quantum Progress
Kuttner and Rosenblum’s “Quantum Enigma” is the best book on quantum physics that I’ve read to date. The table below is my attempt to chronologically summarize some of the well known, brilliant people that led us to where we are today. I found it fascinating that most of the people developed their insights as a result of noticing and pursuing nagging “anomalies” in their work. I also found it fascinating that Einstein was constantly challenging quantum theory even though the math worked flawlessly at predicting outcomes.
The quote that I like most is Bohr’s: “If quantum mechanics hasn’t profoundly shocked you, you haven’t understood it yet”. Well, I don’t understand quantum physics, but I’m still shocked by it. However, since I’ve been consuming all kinds of spiritual teachings over the past 15 years, I’m not surprised by what quantum physics says. Academically “inferior”, but much wiser spiritual teachers have been saying the same thing for thousands, yes thousands, of years. From the Buddha, Lao Tzu, and Jesus, to Krishnamurti, Tolle, and Adyashanti; they didn’t need exotic and esoteric math skills to develop their ideas and thoughts.
Fifty-Fifty
Because of the current economic environment, lots of recycled articles (take charge) regarding continuous education have appeared. Almost every one of them dispenses the same advice: “only you are responsible for continuously educating yourself and keeping your skills up to date”. Of course this is obviously true, but what about an employer’s duty to its stakeholders for ensuring that its workforce has the necessary training and skills to keep the company viably competitive in a rapidly changing landscape? Because of this duty, shouldn’t the responsibility be shared? What about fifty-fifty?
There are at least two ways that corpo managements (if they aren’t so self-absorbed that they’re actually are smart enough to detect the need) react to the need for continuing education of the people that produce its products and provide its services.
- Hire externally to acquire the new skills that it needs
- Invest internally to keep its workforce in synch with the times
Clueless orgs do neither, average orgs do number 1, above average orgs do 2, and great orgs do 1 and 2. Hiring externally can get the right skills in the right place faster and cheaper in the short run, but it can be much riskier than investing internally. Is your hiring process good enough to consistently weed out bozos, especially those that will be placed in positions that require leading people? If it’s a new skill that you require, how can your interviewers (most of whom, by definition, won’t have this new skill) confidently and assuredly determine if candidates are qualified? As everyone knows, face-to-face interviews, references and resumes can be BS smokescreens.
If external competitive pressures require a company to acquire deep, vertical and highly specialized skills, then hiring or renting from the outside may be the right way to go. It may be impractical and untimely to try and train its workforce to acquire knowledge and skills that require long term study. If you have a bunch of plumbers and you need an electrician to increase revenue or execute more efficiently, then it may be more cost effective and timely to hire a trained electrician than to train your plumbers to also become electricians (or it may not).
Which strategy does your corpocracy predominantly use to stay relevant? Number 1, number 2, both, or neither? If neither, why do you think that is the case? No cash, no will, neither?
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.
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?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 