Archive
DICbox Be Gone!
Check out the “DIC in the box” below. The DICbox is drawn around the DICster because that’s the way BMs dehumanize the person behind the DIC label. They do this, of course, in order to make their so-called job easier and to preclude getting their hands dirty with unimportant people. In a BM’s mechanistic mind, all DICs are the same and they’re interchangeable.
In a corpricracy, DICs are given work to do and, if they’re competent and self-motivated, they create high quality work products that increase the wealth of the corpricracy – in spite of the management chicanery that takes place.
The figure below shows an expanded DICbox model with a BM integrated into the system. Since the dude is part Bozo, he doesn’t:
- have a clue (or care) what the work is,
- know (or care) what it takes to do the work,
- know (or care) what the work products are, or how to evaluate them.
That’s why there are no connections in the picture traversing from the work products or work definition flows to the BM. Of course, the BM feigns it as best he can and knows some generic technical buzzwords like “requirements”, “analysis”, “design”, etc. To a BM, all technical projects, from web site development to space shuttle development, are the same – a linear, sequential, unchangeable schedule of requirements, design, coding, testing, and delivery.
Since the BM is in over his head, he must justify his highly compensated existence. He does this via the only option available: behavior watching. Thus, all he essentially does is intently watch for non-conformance of DIC behavior to a set of unwritten and arbitrarily made up corpo rules. He really shines when he detects a transgression and issues the boiler plate “get with the program” speech (a.k.a peek a boo visit) to coerce the DIC back into the box. If that fails, he calls in the big guns – his fellow overhead management dudes in the HR silo. But that’s another story.
OK, OK. So you want to arse me on my own turf and say: “It’s easy to whine and complain about bad management. I’m as good as you are at it.” You follow that up with “How should it be, smarty pants?“. Well here’s one model:
I don’t think the above model needs to be accompanied with much explanation. However, I do think these caveats should be pointed out:
- The DICbox is gone.
- The “BM” label has been replaced by “Leader”.
- The work is co-defined by the leader and the doer.
- The leader knows what the work products should be (work products = “expected outcomes” in management lingo).
- The leader still watches behavior, not as an end in itself, but as a means to help the doer grow, develop, and succeed.
- The leader does what some people (like me) may consider – real work.
ICONIX SysML Training Postscript
Since I’ve noticed that my ICONIX SysML training preview post has received quite a few hits over the past several months and I haven’t written a followup post, I decided that now is the time to do it.
The Bad
When the course was over, I felt very disappointed. Instead of focusing on SysML – which is embedded in the title of the course, SysML was given second class treatment and the main thrusts were centered on:
- Teaching the usage of the big and sprawling Enterprise Architect software modeling and code generation tool
- Teaching a “bent”, non-standard, subset of UML that supports ICONIX’s homegrown software design process: “Use Case Driven Object Modeling“
Only the last (not first) one third of the class handout covered the SysML diagrams and symbolology while the first two thirds covered UML, albeit in a subserviant role to the ICONIX process.
The Good
Although the examples in the handout material were all geared toward database-centric business transaction systems, but my company is in the business of building real-time sensor systems, the teachers facilitated the real time development of a set of use cases, robustness diagrams, and class diagrams for the sensor project we were kicking off. It was a worthwhile team building experience and it surfaced a boatload of ambiguities and misunderstandings between team members. The teachers were skilled facilitators and they did a great job keeping things moving briskly while remaining in the background and not dominating the working sessions.
The Summary
What A Deal!
Do you know those dorky self-promotional license plate holders that car dealers attach to your sparkling new vehicle before you drive it off the lot? Well, the Gold’s gym that I religiously go to has had a stack of them publicly available for sale over the past couple of months. When I first saw them next to the other items for sale, I said to myself:
“WTF? Do the clueless BMs in charge of this place really expect to sell any of those stupid, self-serving contraptions? Hell, even if they offered to pay gym members to take them, they’d still gather dust and waste shelf space until someone in the corpo chain of elites finally took responsibility and owned up to the grumpy they pinched in public.”
About a week ago, management placed the stack of crap right on the check-in counter with a sign that proudly displayed a massive reduction in price from $5 to 1$. What a deal, no?
I finally couldn’t take it anymore and I asked my fellow DIC manning the counter if her management really thought they’d be able to sell those abominations. She said she didn’t know and that she personally hadn’t sold a single one over the time they’d been placed on the market. Surprise!
I left the gym that day suggesting that she tell her bosses that a customer said that they should concentrate more on continuously satisfying their customers instead of thinking of them as moronic walking wallets. As an example of customer satisfaction, I told her to ask “them” if they could refill the woefully deflated balance balls every once in awhile. I even suggested (and it wasn’t the first time) that if they put a pump near the ball rack, I’d fill them occasionally and maybe other users would too. Knowing the typical BM mindset, they probably auto-rejected the idea because they’d be afraid that their “customers” would steal the pump.
How much would you pay for my license plate holder?
BS Design
Sorry, but I couldn’t resist naming the title of this post as it is written. However, despite what you may have thought on first glance, BS stands for dee man, Bjarne Stroustrup. In chapter 23 of “The C++ Programming Language“, Bjarne offers up this advice regarding the art of mid-level design:
To find out the details of executing each iterative step in the while(not_done){} loop, go buy the book. If C++ is your primary programming language and you don’t have the freakin’ book, then shame on you.
Bjarne makes a really good point when he states that his unit of composition is a “component”. He defines a component as a cluster of classes that are cohesively and logically related in some way.
A class should ideally map directly into a problem domain concept, and concepts (like people) rarely exist in isolation. Unless it’s a really low level concrete concept on the order of a built in type like “int”, a class will be an integral player in a mini system of dynamically collaborating concepts. Thinking myopically while designing and writing classes (in any language that directly supports object oriented design) can lead to big, piggy classes and unnecessary dependencies when other classes are conceived and added to the kludge under construction – sort of like managers designing an org to serve themselves instead of the greater community. 🙂
The figure below shows “revision 0” of a mini system of abstract classes that I’m designing and writing on my current project. The names of the classes have been elided so that I don’t get fired for publicly disclosing company secrets. I’ve been architecting and designing software like this from the time I finally made the painful but worthwhile switchover to C++ from C.
The class diagram is the result of “unconsciously” applying step one of Bjarne’s component design process. When I read Bjarne’s sage advice it immediately struck a chord within me because I’ve been operating this way for years without having been privy to his wisdom. That’s why I wrote this blowst – to share my joy at discovering that I may actually be doing something right for a change.
Processes, Threads, Cores, Processors, Nodes
Ahhhhh, the old days. Remember when the venerable CPU was just that, a CPU? No cores, no threads, no multi-CPU servers. The figure below shows a simple model of a modern day symmetric multi-processor, multi-core, multi-thread server. I concocted this model to help myself understand the technology better and thought I would share it.
The figure below shows a generic model of a multi-process, multi-threaded, distributed, real-time software application system. Note that even though they’re not shown in the diagram, thread-to-thread and process-to-process interfaces abound. There is no total independence since the collection of running entities comprise an interconnected “system” designed for a purpose.
Interesting challenges in big, distributed system design are:
- Determining the number of hardware nodes (NN) required to handle anticipated peak input loads without dropping data because of a lack of processing power.
- The allocation of NAPP application processes to NN nodes (when NAPP > NN).
- The dynamic scheduling and dispatching of software processes and threads to hardware processors, cores, and threads within a node.
The first two bullets above are under the full control of system designers, but not the third one. The integrated hardware/software figure below highlights the third bullet above. The vertical arrows don’t do justice to the software process-thread to hardware processor-core-thread scheduling challenge. Human control over these allocation activities is limited and subservient to the will of the particular operating system selected to run the application. In most cases, setting process and thread priorities is the closest the designer can come to controlling system run-time behavior and performance.
D4P And D4F
As some of you may know, my friend Bill Livingston recently finished writing his latest book, “Design For Prevention” (D4P). While doodling and wasting time (if you hadn’t noticed, I like to waste time), I concocted an idea for supplementing the D4P with something called “Design For Function” (D4F). The figure below shows, via a state machine diagram, the proposed marriage of the two complementary processes.
After some kind of initial problem definition is formulated by the owner(s) of the problem, the requirements for a “future” socio-technical system whose purpose is to dissolve the problem are recorded and “somehow” awarded to an experienced problem solver in the domain of interest. Once this occurs, the project is kicked off (Whoo Hoo!) and the wheels start churning via entry into the D4F state. In this state, various structures of connected functions are conceived and investigated for fitness of purpose. This iterative process, which includes short-cycle-run-break-fix learning loops via both computer-based and mental simulations, separates the wheat from the chaff and yields an initial “best” design according to some predefined criteria. Of course, adding to the iterative effort is the fact that the requirements will start changing before the ink dries on the initial snapshot.
Once the initial design candidate is selected for further development, the sibling D4P state is entered for the first (but definitely not last) time. In this important but often neglected problem solving system sub-state, the problem solution system candidate is analyzed for failure modes and their attendant consequences. Additional monitoring and control functional structures are then conceived and integrated into the system design to prevent failures and mitigate those failures that can’t be prevented. The goal at this point is to make the system fault tolerant and robust to large, but low probability, external and internal disturbances. Again, iterative simulations are performed as reconnaissance trips into the future to evaluate system effectiveness and robustness before it gets deployed into its environment.
The figure below shows a dorky model of a system design before and after the D4P process has been executed. Notice the necessary added structural and behavioral complexity incorporated into the system as a result of recursively applying the D4P. Also note that the “Behavior Monitoring” structure(s), be they composed of people in a social system or computers in an automated system, or most likely both, need to have an understanding of the primary system goal seeking functions in order to effectively issue damage prevention and mitigation instructions to the various system elements. Also note that these instructions need not only be logically correct, they need to be timely for them to be effective. If the time lag between real-time problem sensing and control actuating is too great (which happens repeatedly and frequently in huge multi-layered command and control hierarchies that don’t have or want an understanding of what goes on down in the dirty boiler room), then the internal/external damage caused by the system can be as devastating as a cheaper, less complex system operating with no damage prevention capability at all.
So what do you think? Is this D4F + D4P process viable? A bunch of useless baloney?
Ackoff On Systems Thinking
Russell Ackoff, bless his soul, was a rare, top echelon systems thinker who successfully avoided being assimilated by the borg. Checkout the master’s intro to systems thinking in the short series of videos below.
What do you think?
Seeking Trouble
I’ve had the Kindle version of it for awhile, but I’ve finally got around to reading “Gurdjieff” by John Shirley. I’m glad I did because early in the book, this passage stirred up some internal energy:
According to the Gospel of Thomas, Jesus said, ‘ Let him who seeks continue seeking, until he finds. When he finds, he will become troubled. When he becomes troubled, he will be astonished, and he will rule over all.'”
It caused an energy surge because I’ve seeked and found trouble, deep trouble, multiple times. I’ve found that virtually everyone, both individually and collectively, behaves unconsciously according to the selfish “I” thought. Of course, this mass of humanity includes me, especially.
So, I’ve seeked, found trouble, and became astonished. However, I’ve yet to “rule over all”, which I think wasn’t meant to be taken literally. Hell, I’d settle for just ruling over my false self. How about you, have you found trouble?
It’s Gotta Be Free!
I love ironies because they make me laugh.
I find it ironic that some software companies will staunchly avoid paying a cent for software components that can drastically lower maintenance costs, but be willing to charge their customers as much as they can get for the application software they produce.
When it comes to development tools and (especially) infrastructure components that directly bind with their application code, everything’s gotta be free! If it’s not, they’ll do one of two things:
- They’ll “roll their own” component/layer even though they have no expertise in the component domain that cries out for the work of specialized experts. In the old days it was device drivers and operating systems. Today, it’s entire layers like distributed messaging systems and database managers.
- They’ll download and jam-fit a crappy, unpolished, sporadically active, open source equivalent into their product – even if a high quality, battle-tested commercial component is available.
Like most things in life, cost is relative, right? If a component costs $100K, the misers will cry out “holy crap, we can’t waste that money“. However, when you look at it as costing less than one programmer year, the situation looks different, no?
How about you? Does this happen, or has it happened in your company?
Ya Gotta Use This!
It’s interesting when people come off a previous project and are assigned to a new, in-progress, software development project. Often, they demand that their new project team adopt a process/procedure/technique/design/architecture (PPTDA) that they themself used on their previous project.
This can be either good or bad. It can be good if (and it’s a big IF) the alternative PPTDA they are promoting is actually better than the analogous PPTDA currently being employed by the new project team and the cost to integrate the proposed PPTDA into the project environment is less than the additional benefit it brings to the table. It can be really good if the PPTDA has been proven to “work” well and the new project hasn’t progressed past the point where an analogous PPTDA has been decided upon and weaved into the fabric of the project.
On the other hand, a newly proposed PPTDA can be bad in these cases:
- The new project team already has an equivalent PPTDA in place and there’s no “objective” proof that the championed PPTDA really does work better.
- The new project team already has an equivalent PPTDA in place and there’s “objective” proof that the championed PPTDA really does work better, but the cost of social disruption to integrate the PPTDA into the project isn’t worth the benefit.
- The new project team doesn’t have an equivalent PPTDA in place yet and the championed PPTDA has “somehow” been proven to be better than other alternatives, but adopting it would require changes to other well-working PPTDAs that the team is using.
Because there’s a bit of subjectivity in the above list and “rank can be pulled” by a so-called superior in order to jam an unworthy PPTDA into a smoothly running project and muck up the works, be wary of kings bearing gifts.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 