Archive
Yet Another Nit
Programming in C++, I “prefer” composition over inheritance. Thus, for that reason alone, I’d use “ComposedLookupTable” over “InheritedLookupTable” every time:
In addition, since (on purpose) no STL container has a virtual destructor, I’d never even consider inheriting from one – even though those who do would never try to write this monstrosity:
Of course, this can be seen as yet another childish BD00 nitpick. But hey, what else is BD00 gonna do with his time? Solve world poverty? Occupy the org?
Quality is in all the freakin’ details, and when you see stuff like this in product code, it makes you wonder how many other risky, idiom-busting, code frags are lurking within the beast. But alas, where does one draw the line and let things like this slide?
As a final note, beware of disclosing turds like this to their authors; especially in mercenary cultures where everyone is implicitly “expected to” project an image of infallibility in order to “advance” their kuh-rearends. If you can excise turds like this yourself without getting caught, then please do so.
Levels Of Testing
Using three equivalent UML class diagrams, the graphic below conveys how to represent a system design using the “C” terminology of the aerospace and defense industry. On the left, the system “contains” CSCIs and CSCIs contain CSCs, etc. In the middle, the system “has” CSCIs. On the right, CSCIs “reside within” the system.
Leaving aside the question of “what the hell’s a unit“, let’s explore four “levels of testing” with the aid of the multi-graphic below that uses the “reside within” model.
In order to test at any given level, some sort of test harness is required for that level. The test harness “system” is required to:
- generate inputs (for a CSU, CSC, CSCI, or the system),
- inject the inputs into the “Item Under Test” (CSU, CSC, or CSCI),
- collect the actual outputs from the IUT,
- compare the actual outputs with expected outputs.
- declare success or failure for each test
When planning a project up front, it’s easy to issue the mandate: “we’ll formally test and document at all four levels; progressing from the bottom CSU level up to the system level“. However, during project execution, it’s tough to follow “the plan” when the schedule starts to, uh, expand, and pressure mounts to “just shipt it, damn it!“.
Because:
- the number of IUTs in a level decreases as one moves up the ladder of abstraction (there’s only a single IUT at the top – the system),
- the (larger and fewer) IUTs at a given level are richer in complex behavior than the (smaller and more plentiful) IUTs at the next lowest level,
- it is expensive to develop high fidelity, manual and/or automated test harnesses for each and every level
- others?
there’s often a legitimate ROI-based reason to eschew all levels of formal testing except at the system level. That can be OK as long as it’s understood that defects found during final system level testing will be more difficult and time consuming ($$$) to localize and repair than if lower levels of isolated testing had been performed prior to system testing.
To mitigate the risk of increased time to localize/repair from skipping levels of testing, developers can build in test visibility points that can be turned on/off during operation.
The tradeoff here is that designing in an extensive set of runtime controllable test points adds complexity, code, and additional CPU/memory loading to both the system and test harness software. To top it off, test point activation is often needed most when the system is being stressed with capacity test scenarios where the nastiest of bugs tend surface – but the additional CPU and memory load imposed on the system/harness may itself cause tests to fail and mutate bugs into looking like they are located where they are not. D’oh! Ain’t life a be-otch?
Yet Another Occupation
Since, at least for the moment, “occupying” something/anything seems to be the kool, pop-culture thing to do, BD00 has decided to temporarily change his signature graphic – until the next big meme comes along.
Lo and behold, the FAI deviation….
Of course, autographed copies of collector item T-shirts bearing this world-renowned graphic are available for a hefty price that’s affordable only to the top 1%.
BD00 is trying to build a personal “brand” and trying to sloooowly create a “tribe” since those seem to be the other two kool things to do these days. Sheesh, it sure is exhausting trying to keep up with change.
Volunteer Experience
Checkout this tidbit that I e-received from LinkedIn.com:
There are two ways to interpret the “why” of the importance of volunteer work to hiring managers:
- 4 out of 10 managers value compassionate and caring employees
- 4 out of 10 managers value employees who will work lots of unpaid overtime
Maybe its a 50-50 split between the two “whys“?
Biased At Initialization
In “Thinking, Fast and Slow“, Daniel Kahneman asserts:
The normal state of your mind is that you have intuitive feelings and opinions about almost everything that comes your way. You like or dislike people long before you know much about them; you trust or distrust strangers without knowing why; you feel that an enterprise is bound to succeed without analyzing it. Whether you state them or not, you often have answers to questions that you do not completely understand, relying on evidence that you can neither explain nor defend.
Sheesh. So much for initializing the “Bozo Bit” to the unjudgmental MBAB state and then consciously flippin’ it to one state or the other as evidence mounts over time. According to Dr. Dan, because of the lizard-like, “fast thinking” subsystem in our (bozo) brains, the Bozo Bit is biased at initialization to either IAB or INAB.
Turning Inward
As usual, BD00 is delusional and frustratingly confused. Just about every spiritual book I’ve ever read says that one has to turn inward and leap into “the abyss” to experience lasting peace. The implication is that no matter how valiantly hard one tries, an individual can’t find peace, joy, and gratitude “out there“. Thus, frequent calls to “stop the search!” can be found in many spiritual teachings.
On the flip side, several “soft” business and psychology books that I’ve read proffer that turning inward too often may not be such a good idea. Here’s a confirming snippet from Theresa Amabile’s (wonderfully written and highly recommended) “The Progress Principle“:
A 1995 study out of the University of British Columbia showed how research participants who encountered problems in their quest to achieve goals that were personally important to them focused more attention on themselves and spent more time ruminating on those events. Since self-focused attention has often been linked to depression, such findings suggest that people’s emotional well-being can be damaged in the short run when they face discrepancies between goals that are important to their identity or sense of self-worth and what they actually achieved.
“A First-Rate Madness” author Nassir Ghaemi also touches on the downside of turning inward by describing the “depressive realism” hypothesis that can be attributed to tortured leaders like Churchill, Lincoln, and King:
This theory argues that depressed people aren’t depressed because they distort reality; they’re depressed because they see reality more clearly than other people do.
Zen Buddhism is loaded with paradoxical teachings and koans. Ironically, the “logic” is that when the mind can’t resolve two opposing concepts being held in the mind at the same time, at some point the mind eventually gives up on “logic” – providing an opening for peace, joy and gratitude to rush in and fill the void.
So, what do you think? Does turning inward facilitate depression, or peace/joy/gratitude? Is there a half-way point?
He’s In The MIX
Ricardo Semler, one of my innovation heroes, is now a MIXer: Ricardo Semler | Management Innovation eXchange. Until reading his first contribution to the MIX, I hadn’t seen hair nor hide of him for a couple of years. I had thought he’d retired or something like that.
As usual, in his “Retire-a-Little: Enabling More Fulfilled Working Lives“ management hack, Mr. Semler tells the story of yet another heretical and “outrageous” practice that he implemented at Semco Inc. Even if you don’t “buy into” his “retire a little” program, ya gotta love his 3 hour “Are You Nuts?” meetings, no? Try to picture the reception someone would get in your org for suggesting something like an “Are You Nuts?” initiative. Would anyone even attempt to suggest it?
Frag City
As the accumulation of knowledge in a disciplinary domain advances, the knowledge base naturally starts fragmenting into sub-disciplines and turf battles break out all over: “my sub-discipline is more reflective of reality than yours, damn it!“.
In a bit of irony, the systems thinking discipline, which is all about holism, has followed the well worn yellow brick road that leads to frag city. For example, compare the disparate structures of two (terrific) books on systems thinking:
Thank Allah there is at least some overlap, but alas, it’s a natural law: with growth, comes a commensurate increase in complexity. Welcome to frag city…
The Hidden Preservation State
In the software industry, “maintenance” (like “system“) is an overloaded and overused catchall word. Nevertheless, in “Object-Oriented Analysis and Design with Applications“, Grady Booch valiantly tries to resolve the open-endedness of the term:
It is maintenance when we correct errors; it is evolution when we respond to changing requirements; it is preservation when we continue to use extraordinary means to keep an ancient and decaying piece of software in operation (lol! – BD00) – Grady Booch et al
Based on Mr. Booch’s distinctions, the UML state machine diagram below attempts to model the dynamic status of a software-intensive system during its lifetime.
The trouble with a boatload of orgs is that their mental model and operating behavior can be represented as thus:
What’s missing from this crippled state machine? Why, it’s the “Preservation” state silly. In reality, it’s lurking ominously behind the scenes as the elephant in the room, but since it’s hidden from view to the unaware org, it only comes to the fore when a crisis occurs and it can’t be denied any longer. D’oh! Call in the firefighters.
Maybe that’s why Mr. “Happy Dance” Booch also sez:
… reality suggests that an inordinate percentage of software development resources are spent on software preservation.
For orgs that operate in accordance to the crippled state machine, “Preservation” is an expensive, time consuming, resource sucking sink. I hate when that happens.
Human And Automated Controllers
Note: The figures that follow were adapted from Nancy Leveson‘s “Engineering A Safer World“.
In the good ole days, before the integration of fast (but dumbass) computers into controlled-process systems, humans had no choice but to exercise direct control over processes that produced some kind of needed/wanted results. During operation, one or more human controllers would keep the “controlled process” on track via the following monitor-decide-execute cycle:
- monitor the values of key state variables (via gauges, meters, speakers, etc)
- decide what actions, if any, to take to maintain the system in a productive state
- execute those actions (open/close valves, turn cranks, press buttons, flip switches, etc)
As the figure below shows, in order to generate effective control actions, the human controller had to maintain an understanding of the process goals and operation in a mental model stored in his/her head.
With the advent of computers, the complexity of systems that could be, were, and continue to be built has skyrocketed. Because of the rise in the cognitive burden imposed on humans to effectively control these newfangled systems, computers were inserted into the control loop to: (supposedly) reduce cognitive demands on the human controller, increase the speed of taking action, and reduce errors in control judgment.
The figure below shows the insertion of a computer into the control loop. Notice that the human is now one step removed from the value producing process.
Also note that the human overseer must now cognitively maintain two mental models of operation in his/her head: one for the physical process and one for the (supposedly) subservient automated controller:
Assuming that the automated controller unburdens the human controller from many mundane and high speed monitoring/control functions, then the reduction in overall complexity of the human’s mental process model may more than offset the addition of the requirement to maintain and understand the second mental model of how the automated controller works.
Since computers are nothing more than fast idiots with fixed control algorithms designed by fallible human experts (who nonetheless often think they’re infallible in their domain), they can’t issue effective control actions in disturbance situations that were unforeseen during design. Also, due to design flaws in the hardware or software, automated controllers may present an inaccurate picture of the process state, or fail outright while the controlled process keeps merrily chugging along producing results.
To compensate for these potentially dangerous shortfalls, the safest system designs provide backup state monitoring sensors and control actuators that give the human controller the option to override the “fast idiot“. The human controller relies primarily on the interface provided by the computer for monitoring/control, and secondarily on the direct interface couplings to the process.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 