Archive
Incomplete AND Inconsistent
In the early 1900s, Bertrand Russell and Alfred Whitehead published their seminal work, “Principia Mathematica“. Its purpose was to “derive all of mathematics from purely logical axioms” and many smart minds thought they pulled off this Herculean task. However, Kurt Godel came along and busted up the party by throwing a turd in the punch bowl with his blockbuster incompleteness theorem. The incompleteness theorem essentially states that no system of logic can be both consistent and complete. One or the other, but not both.
So, let’s apply Godel’s findings to “logical“, software-intensive systems:
Next, let’s apply the incompleteness theorem to “logical” management systems:
Me thinks that Mr. Spock, one of my all time heroes because of his calm, cool, and collected demeanor and logical genius, was wrong – at least some of the time. Damn that Kurt Godel!
Call For Artists!
Are you a fledgling e-artist who wants to show off his/her work and earn a few bux? If so, then BD00 wants to partner with you in a book project. Like Elton John and Bernie Taupin did with music and lyrics, we can do with graphics and words.
The majority of posts on this site fall into the “management” category. Thus, I’m gonna try to write a self-published e-book that showcases my utter lack of understanding and unparalleled ignorance of the subject. The biggest hurdle I have to overcome is the fear of being sued by Microsoft, and perhaps others, from the commercial use of their graphics. Thus, I need someone to draw up legit replacements for the icons I plan to use in my so-called work; and to be on standby for others that I might need during the effort.
Here’s a categorized collage of images that I need to be redrawn:
If you’re interested, please give me a shout out in the comments section so that we can get the business negotiation process started.
Product Line Blueprint
Here it is, the blueprint (patent pending) you’ve been waiting for:
Need a little less abstraction? Well, how about this refinement:
Piece of cake, no? It’s easy to “figure out“:
- the number of layers needed in the platform,
- the functionality and connectivity within and between each of the layers in the stack
- the granularity of the peer entities that go into each layer and which separates the layers
- the peer-to-peer communication protocols and dependencies within each layer
- the interfaces provided by, and required by, each layer in the stack
- what your horizontally, integrate-able App component set should be for specific product instantiations
- how much time, how much money, and how many people it will take to stand up the stack
- how many different revenue-generating product variants will initially be needed for economic viability
- how to secure all the approvals needed
- how to manage the inevitable decrease in conceptual integrity and increase in entropy of the product factory stack over time – the maintenance problem
Perhaps easiest of all is the last bullet; the continuous, real-time management of the core asset base IF the product factory stack is actually built and placed into operation. After all, it’s not like trying to herd cats, right?
Please feel free to use this open source (LOL!) product line template to instantiate, build, and exploit your own industry and domain specific product line(s). Enough intellectualizing and “strategizing” about doing it in useless committees, task forces, special councils, tiger teams, and blue ribbon panels. There’s money to be made, joy to be distributed, and toes to be stepped on; so just freakin’ do it.
Is this post still too abstract to be of any use? Let’s release some more helium from our balloon and descend from the sky just a wee bit more so that we can get a glimpse of what is below us. Try out “revision 0” of this blueprint instantiation for a hypothetical producer of radar systems:
Did you notice the increase in tyranny of detail and complexity as we transcended the 3 levels of abstraction in this post? Well, it gets worse if we continue on cuz we don’t yet have enough information, knowledge, or understanding to start cutting code, building, testing, and standing up the stack – not nearly enough. Thus, let’s just stop right here so we can retain a modicum of sanity. D’oh! Too late!
Fellow Tribe Members
Being a somewhat skeptical evaluator of conventional wisdom myself, I always enjoy promoting heretical ideas shared by unknown members of my “tribe“. Doug Rosenberg and Matt Stephens are two such tribe members.
Waaaay back, when the agile process revolution against linear, waterfall process thinking was ignited via the signing of the agile manifesto, the eXtreme Programming (XP) agile process burst onto the scene as the latest overhyped silver bullet in the software “engineering” community. While a religious cult that idolized the infallible XP process was growing exponentially in the wake of its introduction, Doug and Matt hatched “Extreme Programming Refactored: The Case Against XP“. The book was a deliciously caustic critique of the beloved process. Of course, Matt and Doug were showered with scorn and hate by the XP priesthood as soon as the book rolled off the presses.
Well, Doug and Matt are back for their second act with the delightful “Design Driven Testing: Test Smarter, Not Harder“. This time, the duo from hell pokes holes in the revered TDD (Test Driven Design) approach to software design – which yet again triggered the rise of another new religion in the software community; or should I say “commune“.
BD00’s hat goes off to you guys. Keep up the good work! Maybe your next work should be titled “Lowerarchy Design: The Case Against Hierarchy“.
Up, Down, Sideways
In order for a tree to remain viable throughout its lifetime, it must grow upwards, sideways (think leaves), and downward (think roots). In BD00’s tortured mind, a lot of people seem myopically focused solely on growing up.
Dream, Mess, Catastrophe
To build high quality, successful, long-lived, “Big” software, you must design it in terms of layers (that’s why the ISO ISO model for network architecture has 7, crisply defined layers). If you don’t leverage the tool of layering (and its close cousin – leveling) in an attempt to manage complexity, then: your baby won’t have much conceptual integrity; you’ll go insane; and you’ll be the unproud owner of a big ball of mud that sucks down maintenance funds like a Dyson and may crumble to pieces at the slightest provocation. D’oh!
The figure below shows a reference model for a layered application. Note that even though we have a neat stack, we can’t tell if we have a winner on our hands.
By adding the inter-layer dependencies to the reference architecture, the true character of our software system will be revealed:
In the “Maintenance Dream“, the inter-layer APIs are crisply defined and empathetically exposed in the form a well documented interfaces, abstractions, and code examples. The programmer(s) of a given layer only have to know what they have to provide to the users above them and what the next layer below lovingly provides to them. Ah, life is good.
Next, shuffle on over to the “Maintenance Mess“. Here, we have crisply defined layers, but the allocation of functionality to the layers has been hosed up ( a violation of the principle of “leveling“) and there’s a beast in the making. Thus, in order for App Layer programmers to be productive, they have to stuff their head with knowledge/understanding of all the sub-layer APIs to get their jobs done. Hopefully, their heads don’t explode and they don’t run for the exits.
Finally, skip on over to the (shhh!) “Maintenance Catastrophe“. Here, we have both a leveling mess and an incoherent set of incomprehensible (to mere mortals) inter-layer APIs. In the worst case: the layers aren’t discernible from one another; it takes “forever” to on-board new project members; it takes forever to fix bugs; it takes forever to add features; and it takes an heroic effort to keep the abomination alive and kicking. Double D’oh!
Forever == Lots Of Cash
In orgs that have only ever created “Maintenance Messes and Catastrophies“, since they’ve never experienced a “Maintenance Dream“, they think that high maintenance costs, busted schedules, and buggy releases are the norm. How do you explain the color green to someone who’s spent his/her whole life immersed in a world of red?
World Class Help
I’m currently transitioning from one software project to another. After two years of working on a product from the ground up, I will be adding enhancements to a legacy system for an existing customer.
The table below shows the software technologies embedded within each of the products. Note that the only common attribute in the table is C++, which, thank god, I’m very proficient at. Since ACE, CORBA, and MFC have big, complicated, “funky” APIs with steep learning curves, it’s a good thing that “training” time is covered in the schedule as required by our people-centric process. 🙂
I’m not too thrilled or motivated at having to spin up and learn ACE and CORBA, which (IMHO) have had their 15 minutes of fame and have faded into history, but hey, all businesses require maintenance of old technologies until product replacement or retirement.
I am, however, delighted to have limited e-access to LinkedIn connection Steve Vinoski. Steve is a world class expert in CORBA know-how who’s co-authored (with Michi Henning) the most popular C++ CORBA programming book on the planet:
Even though Steve has moved on (C++ -> Erlang, CORBA -> REST), he’s been gracious enough to answer some basic beginner CORBA questions from me without requiring a consulting contract 🙂 Thanks for your generosity Steve!
Whole, Part, Purposeful, Unpurposeful
Perhaps ironically, the various branches of “systems thinking” do not have a consensus definition of “system” archetypes. In “Ackoff’s Best”, Russell Ackoff lays down his definition as follows:
There are three basic types of systems and models of them, and a meta-system: one that contains all three types as parts of it. 1. Deterministic: Systems and models in which neither the parts nor the whole are purposeful (e.g. a computer) 2. Animated: Systems and models in which the whole is purposeful but the parts are not (e.g. you or me). 3. Social: Systems and models in which both the parts and the whole are purposeful (e.g. an institution). All three types of systems are contained in ecological systems, some of whose parts are purposeful but not the whole. For example, Earth is an ecological system that has no purpose of its own but contains social and animate systems that do, and deterministic systems that don’t.
But wait! Why are there no Ackoffian systems whose parts are purposeful but whose whole is un-purposeful? Russ doesn’t say why, but BD00 (of course) can speculate.
As soon as one inserts a purposeful part into a deterministic system, the system auto-becomes purposeful?
Range Checked Vector Access
By now, C programmers who’ve made the scary but necessary leap up to C++ should’ve gotten over their unfounded performance angst of using std::vector over raw arrays. If not, then “they” (I hate people like myself who use the term “they“) should consider one more reason for choosing std::vector over an “error prone” array when the need for a container of compact objects arises.
The reason is “range checked access during runtime“; and I don’t mean using std::vector::at() all over your code. Stick with the more natural std::vector::operator[]() member function at each point of use, but use -D_GLIBCXX in the compiler command line of your “Debug” build configuration. (Of course, I’m talking about the GCC g++ compiler here, but I assume other compilers have a similar #define symbol that achieves the same effect.)
The figure below shows:
- A piece of code writing into the 11th element of a std::vector that is only 5 elements long (D’oh!).
- A portion of the compiler command line used to build the Release (left) and Debug (right) configurations.
- The console output after running the code.
In contrast, here’s what you get with a bad ole array:
The unsettling aspect about the three “D’oh” result cases (unlike the sole “no D’oh” case) is that the program didn’t crash spectacularly at the point of error. It kept humming along silently; camouflaging the location of the bug and insidiously propagating the error effect further downstream in the thread of execution. Bummer, I hate when that happens.
Complementary Views
One classic definition of a system is “a set of interacting parts that exhibits emergent behavior not attributable solely to one part“. An alternative, complementary definition of a system served up by Russell Ackoff is “a whole that is defined by its function in a larger system of which it is a part“.
The figure below models the first definition on the left and the second definition on the right. Neither is “righter” than the other. They, and I love saying this because it’s frustratingly neutral, “just are“.
Viewing a system of interest from multiple viewpoints provides the viewer with a more holistic understanding of the system’s what, how, and why. Problem diagnosis and improvement ideas are vastly increased when time is taken to diligently look at a system from multiple viewpoints. Sadly, due to how we are educated, the inculcated tendency of most people is to look at a system from a single, parochial viewpoint: “what’s in it for me?“.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 