Archive
Reckless Meritocracies
Being a staunch advocate of democratic meritocracy, when I stumbled across the title of this potentially UCB-loosening op-ed by Ross Douthat; “Our Reckless Meritocracy“, I dove right in. I was intrigued by the use of the word “reckless” in the title.
Ross commences his opinion piece by telling the rags-to-riches-to-rags story of Jon Corzine:
- Boy grows up in rural Illinois
- Boy’s grandfather was a farmer who lost everything in the great depression
- Boy graduates from Illinois state university
- Boy goes into Marine Corps
- Boy gets MBA
- Boy works for regional bank
- Boy works for Goldman Sachs
- Boy becomes Goldman Sachs CEO
- Boy serves in US senate
- Boy serves as governer of NJ
- Boy returns to Wall St. as CEO of MF Global
- MF Global files for bankruptcy after “mislaying” $600M
- Boy resigns in disgrace (but with plenty of dough in the bank)
Ross uses this lead-in to postulate that the US has “created what seems like the most capable, hardworking, high-I.Q. elite in all of human history – and we’ve watched this same elite lead us off a cliff“.
Ross then theorizes on how catastrophies are perpetrated by the rich and powerful in reckless meritocracies, hereditary aristocracies, and one-party states:
- Hereditary aristocracies: debacles caused by stupidity and pigheadedness
- One Party States: debacles caused by ideological mania
- Reckless Meritocracies: debacles caused by hubris
Relative to the other two forms of governance, at least scores of little people aren’t physically massacred in reckless meritocracies. They’re simply thrust into poverty. The real genius of reckless meritocracy is that when a meritocrat falls, he/she isn’t beheaded. At worst, he/she goes to jail. At best, he/she gets away with a huge bag of loot.
So, what’s a democratically run institution to do? Mr. Douthat rightly states that “it will do America no good to replace the arrogant with the ignorant, the overconfident with the incompetent“. (Didn’t you see the movie “Idiocracy“?)
We need intelligent leaders with a sense of their own limits, experienced people whose lives have taught them caution. We still need the best and brightest, but we need them to have somehow learned humility along the way. – Ross Douthat
If you made it thus far into this post, you may be wondering why BD00 is wasting your time by simply parroting Ross Douthat in yet another meta-blog post? It’s because BD00 wanted to display his fledgling UML skill again:
But wait! It may ironically be because of BD00’s own personal lack of humility and the fact that BD00 gets off on reading funny spammer comments like these:
Spiritual UML
Because he is the chosen one, the universe spaketh to BD00 last night: “Go forth my son, and employ the UML to teach the masses the true nature of the mind!“. Fearful of being annihilated if he didn’t comply, BD00 sat down and waited for an infusion of cosmic power to infiltrate his being (to catalyze the process, BD00 primed the pump with a three olive dirty ‘tini and hoped the universe didn’t notice).
With mouse in trembling hand and an empty Visio canvas in front of him, BD00 waited…. and waited… and waited. Then suddenly, in mysterious Ouja board fashion, the mouse started moving and clicking away. Click, click, click, click.
After exactly 666 seconds, “revision 0” was 90% done. The secrets of the metaphysical that have eluded the best and brightest over the ages were captured and revealed in the realm of the physical! Lo and behold….. the ultimate UML class diagram:
Of course, the “Thought Factory” class is located in China. It efficiently and continuously creates (at rock bottom labor costs) every thought that comes/stays/goes through each of the 7 billion living brains on earth.
Design Disclosure
Recently, I had to publicly disclose the design of the multi-threaded CSCI (Computer Software Configuration Item) that I’m currently bringing to life with a small group of colleagues. The figure below shows the entities (packages, CSCs (Computer Software Components), Classes) and the inter-entity relationship schema that I used to create the CSCI design artifacts.
As the figure illustrates, the emerging CSCI contains M packages and K top level CSCs . Each package contains from 1 to N 2nd level CSCs that associate with each other via the “communicates” (via messages) relationship. Each CSC is of the “passive” or “active” class type, where “active” means that the CSC executes within its own thread of control.
Using the schema, I presented the structural and behavioral aspects of the design as a set of views:
- The threads view (behavioral )
- The packages view (structural)
- The class diagrams view (structural)
- The sequence diagrams view (behavioral)
Like any “real” design effort (and unlike the standard sequential design-code-test mindset of “authorities“), I covertly used the incremental and iterative PAYGO methodology (design-a-little, code-a-little, test-a-little, document-a-little) in various mini sequences that, shhhh – don’t tell any rational thinker, just “felt right” in the moment.
As we speak, the effort is still underway and, of course, the software is 90% done. Whoo Hoo! Only 10 more percent to go.
“As-Built” Vs “Build-To”
The figure below shows one (way too common) approach for developing computer programs. From an “understanding” in your head, you just dive into the coding state and stay there until the program is “done“. When it finally is “done“: 1) you load the code into a reverse engineering tool, 2) press a button, and voila, 3) your program “As-Built” documentation is generated.
For trivial programs where you can hold the entire design in your head, this technique can be efficient and it can work quite well. However, for non-trivial programs, it can easily lead to unmaintainable BBoMs. The problem is that the design is “buried” in the code until after the fact – when it is finally exposed for scrutiny via the auto-generated “as-built” documentation.
With a dumb-ass reverse engineering tool that doesn’t “understand” context or what the pain points in a design are, the auto-generated documentation is often overly detailed, unintelligible, camouflage in which a reviewer/maintainer can’t see the forest for the trees. But hey, you can happily tick off the documentation item on your process checklist.
Two alternative, paygo types of development approaches are shown below. During development, the “build-to” design documentation and the code are cohesively produced manually. Only the important design constructs are recorded so that they aren’t buried in a mass of detail and they can be scrutinized/reviewed/error-corrected in real-time during development – not just after the fact.
I find that I learn more from the act of doing the documentation than from pushing an “auto-generate” button after the fact. During the effort, the documentation often speaks to me – “there’s something wrong with the design here, fix me“.
Design is an intimate act of communication between the creator and the created – Unknown
Of course, for developers, especially one dimensional extreme agilista types who have no desire to “do documentation” or learn UML, the emergence of reverse engineering tools has been a Godsend. Bummer for the programmer, the org he/she works for, the customer, and the code.
New UML Apparel!
If you don’t know yet (and you prolly don’t, since about two fellow, hapless people read this blog and one of them uses the word “fish” in his sign on name when he occasionally comments on a post), my company, the Sensis Corporation, has been purchased by SAAB AB of Sweden. Since the deal concerns the purchase of an American aerospace and defense company by a foreign enterprise, the deal has yet to be sanctioned by the U.S. government. However, in preparation for a successful closing, I’m contemplating proposing the following logo and SAAB-Sensis subsidiary apparel for sale.
The SAAB-Sensis logo, which is anchored on the UML “has a” relationship, is intended to kill two birds with one stone. It’s intended to promote both SAAB and Sensis; and it promotes the UML standard for representing software-centric systems. The scheme is sort of like the SNL product that’s both a desert topping and a floor wax. (If you think I’m nutz, then you’re in the majority.)
Of course, if the logo gets adopted, the idea goes viral, and the orders start pouring in, I’ll fully expect a hefty percentage of the sale from each item in the portfolio.
Requirements Stability
Over the years, I’ve been assigned to the roles of specifier, designer, documenter, writer, and maintainer of source code for radar sensor systems that are used in safety-critical applications. These sensors get deployed in noisy, interference-infested environments and they must perform at high levels of availability and with great fidelity.
The figure below shows a generic sensor system context diagram along with some typical non-functional requirements (with made-up values) that are critical for customer acceptance. My experience has indicated that once these black-box level requirements are specified, they rarely change. Thus, the agile war cry to continuously “embrace requirements change” may not fully apply to the development of this class of systems, no?
The point I’m trying to make here is to be wary of morphing into a lap-dog zealot for any technique, process, method, or practice – which includes the hallowed “agile” brand. For a long time, my motto (thanks to the work of W. L. Livingston and John Warfield) has been: Context, Content, and then Process (CCP). Synthesize an understanding of the problem context, design the content of the solution (structure and behavior), and only then design the solution construction process – tailored to the context and content. Of course, since mistakes and errors will be made during the journey, backtracking and iterative convergence are expected. Thus, “embrace mistakes, errors, backtracking, and iteration” is my war cry. What’s yours? What’s your org’s?
SysML Support For Requirements Modeling
“To communicate requirements, someone has to write them down.” – Scott Berkun
Prolific author Gerald Weinberg once said something like: “don’t write about what you know, write about what you want to know“. With that in mind, this post is an introduction to the requirements modeling support that’s built into the OMG’s System Modeling Language (SysML). Well, it’s sort of an intro. You see, I know a little about the requirements modeling features of SysML, but not a lot. Thus, since I “want to know” more, I’m going to write about them, damn it! 🙂
SysML Requirements Support Overview
Unlike the UML, which was designed as a complexity-conquering job performance aid for software developers, the SysML profile of UML was created to aid systems engineers during the definition and design of multi-technology systems that may or may not include software components (but which interesting systems don’t include software?). Thus, besides the well known Use Case diagram (which was snatched “as is” from the UML) employed for capturing and communicating functional requirements, the SysML defines the following features for capturing both functional and non-functional requirements:
- a stereotyped classifier for a requirement
- a requirements diagram
- six types of relationships that involve a requirement on at least one end of the association.
The Requirement Classifier
The figure below shows the SysML stereotyped classifier model element for a requirement. In SysML, a requirement has two properties: a unique “id” and a free form “text” field. Note that the example on the right models a “non-functional” requirement – something a use case diagram wasn’t intended to capture easily.
One purpose for capturing requirements in a graphic “box” symbol is so that inter-box relationships can be viewed in various logically “chunked“, 2-dimensional views – a capability that most linear, text-based requirements management tools are not at all good at.
Requirement Relationships
In addition to the requirement classifier, the SysML enumerates 6 different types of requirement relationships:
A SysML requirement modeling element must appear on at least one side of these relationships with the exception of <<derivReqt>> and <<copy>>, which both need a requirement on both sides of the connection.
Rather than try to write down semi-formal definitions for each relationship in isolation, I’m gonna punt and just show them in an example requirement diagram in the next section.
The Requirement Diagram
The figure below shows all six requirement relationships in action on one requirement diagram. Since I’ve spent too much time on this post already (a.k.a. I’m lazy) and one of the goals of SysML (and other graphical modeling languages) is to replace lots of linear words with 2D figures that convey more meaning than a rambling 1D text description, I’m not going to walk through the details. So, as Linda Richman says, “tawk amongst yawselves“.
References
1) A Practical Guide to SysML: The Systems Modeling Language – Sanford Friedenthal, Alan Moore, Rick Steiner
2) Systems Engineering with SysML/UML: Modeling, Analysis, Design – Tim Weilkiens
Synthanalysis
According to Russell Ackoff, there are two thinking tools for developing an understanding of how existing socio-technical systems work: analysis (reductionism) and synthesis (constructionism). Since analysis is taught in school (and synthesis is not – except in the arts), analysis is a well known tool to problem solvers. Synthesis is not taught in schools because it’s hard to teach – it’s a less methodical and more metaphysical technique than analysis.
The UML state machine diagram below models the behavior of two different problem solvers – one that exclusively uses analysis and one that bounces non-deterministically between analysis and synthesis. Note that the purpose of entering and dwelling in the synthesis state is to learn the holistic “why” of a system – which always lies outside of the system.
The figure below shows a typical example trace of a synthanalyst problem solver’s behavior over time. Over each iteration toward a viable solution to the problem at hand, a synthanalyst dwells less and less in the synthesis state and more and more in the analysis state. The behavior trace for a one dimensional analyzer is not shown because it’s trivial. It’s a boring and unadventurous flat line – one that self-smug managers trace out every day at work.
SysML, UML, MML
I really like the SysML and UML for modeling and reasoning about complex, multi-technology and software-centric systems respectively, but I think they have one glaring shortcoming. They aren’t very good at modeling distributed, multi-process, multi-threaded systems. Why? Because every major element (except for a use case?) is represented as a rectangle. As far as I know, a process can be modeled as either a parallelogram or a stereotyped rectangular UML class (SysML block ):
To better communicate an understanding of multi-threaded, multi-process systems, I’ve created my own graphical “proprietary” (a.k.a. homegrown) symbology. I call it the MML (UML profile). Here is the MML symbol set.
An example MML diagram of a design that I’m working on is shown below. The app-specific modeling element names have been given un-descriptive names like ATx, APx, DBx, Mx for obvious reasons.
Compare this model with the equivalent rectangular UML diagram below. I purposely didn’t use color and made sure it was bland so that you’d answer the following question the way I want you to. Which do you think is more expressive and makes for a better communication and reasoning tool?
If you said “the UML diagram is better“, that’s OK. 🙂
Which One, And When?
Option A and Option B in the UML figure below show two different ways of presenting the same 3-function interface to “other” code users. Under which conditions would you choose one design over the other?
Because I prefer simplicity over complexity and local dependency over distant dependency, I’d prefer option B over option A if I was reasonably sure that classes A and B wouldn’t be useful in another inheritance tree or useful as leaf classes. Even if I chose wrongly, because all the functionality is encapsulated within one class in option B, it wouldn’t be a huge risk for a user to extract out B or C class sub-functionality from D and customize it for his/her use by placing it in his/her own separate E class. In this case, no other existing clients of class D would be affected, but the trade off is the introduction of duplicate code into the code base. If I chose the option A inheritance tree, this wouldn’t be the case. In option A, if a user was allowed to directly change A and/or B in-situ, then the duplicate code “wart” wouldn’t manifest, but the risk of breaking the existing code of other users of the A, B, and/or C classes would be high compared to the alternative. Do you see any holes in this decision logic?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 