Archive
Revoked Membership
In Stop Coddling the Super-Rich, Warren Buffet states:
My friends and I have been coddled long enough by a billionaire-friendly Congress. It’s time for our government to get serious about shared sacrifice. – Warren Buffet
OUR leaders have asked for “shared sacrifice.” But when they did the asking, they spared me. I checked with my mega-rich friends to learn what pain they were expecting. They, too, were left untouched. – Warren Buffet
As Vineet Nayar is to CEOs, Warren Buffet is to the super-rich. I luv both those guys. What about you?
Pick Your Tyranny
Given the choice between “tyranny of the majority” and “tyranny of the minority“, I’d choose the former every time – especially when the minority is a junta in the latter case. In representational democracies like the good ole USA, the “representational” aspect decreases the chance of being governed by the “tyranny of the majority“. In really bad corpricracies, the “tyranny of the minority” is the rule and, since it’s a subtle form of tyranny, everyone up and down the ladder of importance accepts it in quiet desperation – with no questions asked.
Manager Types II
This post is an updated refinement of BD00’s class hierarchy for the manager types previously presented in the UCBH post. For your viewing displeasure, I’ve reproduced the “rev 0” version of the inheritance tree here:
The “rev 1” version, with all class operations elided because they’re not important for understanding the message I want to get across, is shown below. The absence of the “Tweener” in rev 0, which inherits the attributes and operations from both the “Bozo” and “Helper” classes, was a major mistake.
“Rev 1” is a much more accurate mental model of the manager kingdom because, as the probability density function below shows, the vast majority of manager “objects” are of the relatively boring, harmless, and ho-hum “Tweener” type.
If you look closely at the threshold locations in the scraggly drawn probability distribution, BD00 has postulated that even though the population is comprised mostly of “Tweeners“, there are more BMs than PHORs. Do you agree?
Luckily and happily, BD00 has never worked for, or with, a conscious BM. But he’s directly heard, and indirectly read, several stories from those poor souls who have (are you one of them?). Thus, BD00 is convinced that they do exist in nature.
All models are wrong. Some, however, are useful – George Box
More What?
My dog “Morrie” is a beautiful creature. On top of that, he’s uh hilariously dumb ass in the mould of his human step father. Depending on the situation we’re involved in together, I either call him “More-Easter“, or “More-Keester“. Every once in awhile, I call him by his real name, “Morrie”, so he doesn’t fugget it. I call him “More-Easter” (like the Nor’easter storm and not the dogmatic christian easter) when he’s wreaking havoc, and “More-Keester” when he’s acting like his dad; a keester. Which nickname do ya think I use more frequently?
Desired And Actual
Raising Ire
I’m a member of several C++ programming groups on LinkedIn.com. Because I’m passionate about programming and software engineering, I like to share links to what I think are interesting C++ articles to the groups.
Bam! Out of the blue, I get this BS “warning” from a hot shot moderator of one of the groups:
After challenging this self-important dude to point out some examples of “off topic” postings, to define excessive “posting frequency“, and to provide the name of my accuser, I received silence.
Out of curiosity, I contacted the group owner and asked WTF was going on. He checked into the situation and said that I wasn’t posting too frequently (of course, there IS no rule about posting “too frequently“) and that he enjoyed my posted links. Nevertheless, I quit the group since there are many other C++ groups to contribute to without being hassled by a power monger and control freak. Life is too short.
Via a simple analysis of the content in the “scary” warning message, I arrived at the conclusion that the dude was reading this bogus blog and got pissed off cuz he is either a BM or a BM wannabe – and the shoe fit. So, I sent a message to Mr. God and suggested:
“If my blog upsets you, then don’t read it.”
Of course, since he didn’t admit to it, I don’t know fer sure if Mr. little Hitler stumbled onto this blog and blew his stack . But, as you know, BD00 is prone to making stuff up and bouts of wild speculation. D’oh!
The Emergence Of The STL
In the preface to the 2006 Japanese translation of “The Design and Evolution of C++“, Bjarne Stroustrup writes about how the C++ STL containers/iterators/algorithms approach to generic programming came into being. Of particular interest to me was how he struggled with the problem of “intrusive” containers:
The STL was a revolutionary departure from the way we had been thinking about containers and their use. From the earliest days of Simula, containers (such as lists) had been intrusive: An object could be put into a container if and only if its class had been (explicitly or implicitly) derived from a specific “Link” or “Object” class containing the link information needed by the compiler (to traverse the container). Basically, such a container is a container of references to Links. This implies that fundamental types, such as ints and doubles, can’t be put directly into containers and that the array type, which directly supports fundamental types, must be different from other containers. Furthermore, objects of really simple classes, such as complex and Point, can’t remain optimal in time and space if we want to put them into a container. It also implies that such containers are not statically type safe. For example, a Circle may be added to a list, but when it is extracted we know only that it is an Object and need to apply a cast (explicit type conversion) to regain the static type.
The figure below illustrates an “intrusive” container. Note that container users (like you and me) must conform to the container’s requirement that every application-specific, user-defined class (Element) inherits from an “overhead” Object class in order for the container to be able to traverse its contents.
As the figure below shows, the STL’s “iterator” concept unburdens the user’s application classes from having to carry around the extra overhead burden of a “universal“, “all-things-to-all people”, class.
The “separation of concerns” STL approach unburdens the user by requiring each library container writer to implement an Iterator class that knows how to move sequentially from user-defined object to object in accordance to how the container has internally linked the objects (tree, list, etc) and regardless of the object’s content. The Iterator itself contains the container-specific equivalent navigational information as the Object class in the “intrusive” container model. For contiguous memory type containers (array, vector), it may be implemented as a simple pointer to the type of objects stored in the container. For more complex containers (map, list) the Iterator may contain multiple pointers for fast, container-specific, traversal/lookup/insertion/removal.
I don’t know about you, but I think the STL’s implementation of containers and generic programming is uber cool. It is both general AND efficient – two desirable properties rarely found together in a programming language library:
…the performance of the STL is that it – like C++ itself – is based directly on the hardware model of memory and computation. The STL notion of a sequence is basically that of the hardware’s view of memory as a set of sequences of objects. The basic semantics of the STL maps directly into hardware instructions allowing algorithms to be implemented optimally. The compile-time resolution of templates and the perfect inlining they support is then key to the efficient mapping of high level expression of the STL to the hardware level.
The Elephants In The Room
One of the originators of RUP and the creator of the 4+1 view modeling approach, Phillippe Kruchten, has written a terrific article on the “twenty elephants in the room” that haunt the agile movement. Here’s a subset of his infamous list that resonates with me:
- Commercial interests censoring failures (tell me about the failures).
- Failure to dampen negative behaviours (no analysis of failures).
- Context and contextual applicability of practices (can you say “safety-critical systems“?)
- Anarchism (preventing a more systematic organization of the body of knowledge).
- Elitism (blame failure on the “unenlightened” others)
- Certification (effective tool to assess maturity for individuals and organization, or commercial ploy from trainers and consultants to rake in the dough?)
- Role of architecture and design (they are still often equated to BUFD, and rapidly brushed aside with claims of YAGNI, or “we’ll refactor it later”)
- Scaling naïveté (with a bit of imagination all agile practices scale up, and if this does not work it is because you have not tried hard enough).
- Technical debt (while agile practices could help control technical debt, they are also often at the root, the cause of massive technical debt).
- Effective ways of discovering information without writing source code (uh, can you say “modeling“?).
Of course, because of his involvement in the development of the perceived horrible, heavyweight, RUP process, extreme agilistas will not even listen to Phillippe’s ideas – let alone ponder the validity of any of them.
DataLoggerThread
The figure below models a program in which a pipeline of worker threads communicate with each other via message passing. The accordion thingies ‘tween the threads are message queues that keep the threads loosely coupled and prevent message bursts from overwhelming downstream threads.
During the process of writing one of these multi-threaded programs to handle bursty, high rate, message streams, I needed a way to periodically extract state information from each thread so that I could “see” and evaluate what the hell was happening inside the system during runtime. Thus, I wrote a generic “Data Logger” thread and added periodic state reporting functionality to each worker thread to round out the system:
Because the reporting frequency is low (it’s configurable for each worker thread and the default value is once every 5 seconds) and the state report messages are small, I didn’t feel the need to provide a queue per worker thread – YAGNI.
The figure below shows a more detailed design model of the data logging facility in the form of a “bent” UML class diagram. Upon construction, each DataLoggerThread object can be configured to output state messages to a user named disk file and/or the global console during runtime. The rate at which a DataLoggerThread object “pops” state report messages from its input queue is also configurable.
The DataLoggerThread class provides two different methods of access to user code at runtime:
void DataLoggerThread::record_txt_block(const Data&)
and
void DataLoggerThread::operator<<(const Data&).
Objects of the DataLoggerThread class run in their own thread of execution – transparently in the background to mainline user code. On construction, each object instance creates a mutex-protected, inter-thread queue and auto-starts its own thread of operation behind the scenes. On destruction, the object gracefully self-terminates. During runtime, each DataLoggerThread object polls its input queue and formats/writes the queue entries to the global console (which is protected from simultaneous, multiple thread access by a previously developed CoutMonitor class) and/or to a user-named disk log file. The queue is drained of all entries on each (configurable,) periodic activation by the underlying (Boost) threads library.
DataLoggerThread objects pre-pend a “milliseconds since midnight” timestamp to each log entry just prior to being pushed onto the queue and a date-time stamp is pre-pended to each user supplied filespec so that file access collisions don’t occur between multiple instances of the class.
That’s all I’m gonna disclose for now, but that’s OK because every programmer who writes soft, real-time, multi-threaded code has their own homegrown contraption, no?
















