Archive
What’s Up With Featured Blogs?
WordPress.com provides the capability for users to browse blog posts by clicking on a subject tag. After clicking on a tag of interest, the results page displays a bunch of blog posts that authors have marked with that tag. As the (egotistical and self-serving) screen snippet below illustrates, the first listed blog post at the top of the page is somehow designated as the “featured blog“.
Out of curiosity (which is judged as a sin inside of most religious and corpo institutions), I briefly searched for the criteria/algorithm that wordpress.com uses to select the “featured blog” of the day, but I couldn’t find it. However, I did find a bunch of vain, self-congratulatory posts just like this yawner.
Real-Time, Face-To-Face
Criticism is something we can avoid easily by saying nothing, doing nothing, and being nothing. – Aristotle
Ain’t that the truth? You can’t relate to it because you keep your trap shut out of fear of reprisal, no? Don’t worry, you’re not alone. Gracefully giving and (especially) receiving criticism in real-time, face-to-face is an art that I haven’t mastered. In those rare cases where I’m giving or receiving, either I’m meekly submissive or I blow a gasket; mostly the latter. Unlike when I’m blogging or e-mailing (a.k.a hiding behind the keyboard like a lot of engineers do), I’m too spontaneous to ponder, agonize over, and cunningly strategize over every word.
In corpricracies, criticism (real-time and face-to-face, or electronically) directed upward from the boys and girls down in the boiler room is verboten via one of the many rules written in invisible corpo ink, no? If not, then what purpose does the invention of anointed titles and structured CCH caste systems serve? What’s the purpose of the term “individual contributor” other than to divide and conquer? What’s the purpose of statements that start with “Effective immediately, management has decided…” other than to subtlely imply who’s allowed to criticize whom? How often do conquerees criticize conquerers, and when they miraculously do decide to profer some criticism, what’s the typical outcome? A subtle, unseen, but intensely felt top down psychological whuppin’?
On the bright side, at least civilization has “matured” from the time when the messenger who served up a pu pu platter was literally beheaded, no?
“The problem with any unwritten law is that you don’t know where to go to erase it.” – Glaser and Way
Relatively Lean
As this not-too-out-of-date blog post details, “My Company“, I work for Sensis Inc. According to this unscientific, but interesting chart from LinkedIn.com (computed from it’s membership data) we’re leaner than our fatty competitors. Our R&D to G&A ratio seems to be quite higher than most other “similar” companies. Encouraging, no?
Stylistic Versatility
Except for his interviews with several famous people that were involved in the development of successful software systems, consuming Sam Lightstone’s “Making It Big In Software” didn’t do a whole lot for me. However, when he wasn’t writing like a know-it-all patriarch, Sam did provide several nuggets of wisdom to absorb. One of those nuggets was the disclosure of Hay & McBer’s 6 leadership styles as uncovered via a study of 3,871 executives. For your convenience (uh, actually my convenience), I’ve copied and pasted the leadership style table below.
Lightstone rightly says that the versatile leader (and how many versatile, multidimensional leaders do you know?) applies the right style at the right time:
- Use coercion only in crises situations
- Use authority when charting a new course
- Use affiliation to heal a team
- Use democracy for collaboration
- Use pacesetting for sprints
- Use coaching for improvement
Regarding effectiveness of style, Lightstone writes:
Although each style has its pros and cons, (Daniel) Goleman’s article citing the Hay and McBer research found that the coercive and pacesetting styles have the most negative impact on an organizations. Nobody likes to be bullied, and the hallmark of a coercive style is a dictatorial approach. Pacesetting styles force employees to run at a pace that might not be comfortable or sustainable for them.
I think that BOOGLs, BUTTs, and CGHs, of which there are many, are one dimensional SCOLs who apply the only style they know, coercion, in all situations. These one-trick-pony dudes and dudettes either don’t believe the other five styles exist, or they don’t utilize the styles because they’re expected to be “in control” at all times by the toxic culture that pervades the corpricracy.
I’m not a leader, so I don’t/can’t practice applying any of the Hay & McBer styles. How about you? Are you a versatile leader, or are you a culturally conditioned control freak?
Transfer Of Mental Ownership
I don’t know how to write code in the Erlang programming language, but ever since reading Bjarne Stroustrup‘s “The Design And Evolution Of C++“, I’ve been interested in the topic of programming language creation, development, and adoption. Sinisterly, I look for how much support, or lack thereof, that management provided to the language creators.
In this entertaining InfoQ video, “A Discussion Of Basic vs. Applied Research In The Software Domain And The Creation Of Erlang“, kindly and soft-spoken Bjarne Dacker recounts the development of Erlang. Here are some of my distorted notes:
Many problems that need to be solved by software are not computationally intensive, they’re symbolic.
The sequential and synchronous Von Neumann programming model does not map cleanly into the realm of real-time control systems.
The Erlang team asked: “Why are software academics obsessed with all these subtle, disparate, awkward, and complicated communication schemes like buffers, semaphores, mailboxes, rendezvous, regions, pipes? Why not just simply send messages between asynchronously running processes?”
Erlang designers took the goodies from Modula, Ada, and Chill and discarded the baddies.
By being devious and cunning, Dacker was able to subvert the corpo bureaucratic mandate that “everybody shall use the centralized IBM mainframe” and he miraculously secured approval to purchase a dedicated VAX (close to state of the art at the time) computing platform for his team.
Ericsson management wanted Erlang to be proprietary; a secret weapon that would allow them to develop their telecommunication products faster than their competitors. On the other hand, Ericsson management disallowed the usage of Erlang internally because it wasn’t an open standard (LOL!).
You can’t just throw new technology over the wall to product teams. You must create mixed teams; embedding applied researchers within product teams. You must facilitate the transfer of “mental ownership”.
In 2009, “something” happened. The number of Erlang downloads at Erlang.org started to skyrocket.
In keeping with my goal of providing a dorky graphic with each blog post, I present Mr. Dacker’s process for the successful transition of applied research knowledge into the marketplace.
Notice that going “backward” and cycling multiple times through the mistake prone experiment/evaluate activities (which most sequential, linear, forward-only management CGHs abhor and forbid) is an integral part of Dacker’s process. The mixing of researchers with product developers occurs in the production/exploitation stage.
Priority List
In his brilliant and elegant essay, “Capitalism is Dead. Long Live Capitalism“, Gary Hamel laments about the deterioration of capitalism into those other bad, highly inequitable, anti-American “isms”. He says:
So why do fewer than four out of ten consumers in the developed world believe that large corporations make a “somewhat” or “generally” positive contribution to society? Why is it that only 19% of Americans tell pollsters they have “quite a lot” or a “great deal” of confidence in big business?
In Gary’s opinion, the reason is……
… the unwillingness of executives to confront the changing expectations of their stakeholders. In recent years, consumers and citizens have become increasingly disgruntled with the implicit contract that governs the rights and obligations of society’s most powerful economic actors—large corporations. To many, the bargain seems one-sided—it’s worked well for CEOs and shareholders, but not so well for everyone else.
This lead-in dovetails into the idea of a “CEO stakeholder priority list“. The UML class diagram below shows six types of corpo stakeholders. Of course, the six types were arbitrarily picked by me and there may be others on the same level of abstraction that you think are missing. Notice that the “earth” is a passive stakeholder that can’t directly and instantaneously exert pressure on the way corpricracies behave; unlike the other people-type stakeholders.
Now, check out some sample CEO stakeholder priority lists below. With 6 stakeholders types, the number of unique lists is quite a lot: 6! = 6 x 5 x 4 x 3 x 2 = 720. I just semi-randomly concocted these three specific sample lists so that I can continue babbling on while hoping that you’re still reading my drivel.
My own unscholarly opinion is that the vast majority of CEOs, their appointed-yes-men VP teams, and their hand picked boards of directors either consciously or unconsciously operate according to the blue list (or any other instance that prioritizes the “executives” stakeholder first). My opinion aligns with Mr. Hamel’s assertion that too many corpo captains are making decisions that materially favor themselves (first) and their shareholders while disproportionately harming the other stakeholder types.
But wait, hasn’t this always been the case with capitalism? If so, why has it suddenly become fashionable for dweebs like me to vilify corpricracies that operate in accordance with the blue list?
In closing, I feel the need to repeat the best quote in Hamel’s blarticle:
There are CEOs who still cling to the belief that a company is first and foremost an economic entity rather than a social one. – Gary Hamel
To those CEOs who still think that the word “social” equates to communism, get over it and move into this century.
The DORK Is Born
Unlike upstanding citizens, I’m both internally and externally verbally weird. For example, I think that when a proven, in-the-trenches, problem-solving, core worker jumps ship to another org it often hurts a corpricracy more than when a BM, CCRAT, BUTT, CGH or other non-DORK leaves. Because of anointed (not necessarily earned) positional power, non-DORK managerial workers are given the opportunity to positively influence an org’s social and economic performance. However, as all of us know, not all managers exert any positive influence at all. Au contraire, the really “bad ones” just flit from meeting to meeting conjuring up innovative procedural and financial obstacles to getting work done while simultaneously collecting super-sized paychecks. Who says managers aren’t innovative?
Because of this so-called distorted (and “bad”?) attitude, it makes me laugh when I hear of frantic counter offers being made when non-DORK managers leave, while nary a whisper is uttered when a highly productive, problem solving DORK rides off into the sunset. I laugh even more heartily when a non-DORK SCOL is presented with a going away cake or even better; an org-financed buh-bye party. Why laugh? Because the alternatives are much less palatable.
Breaking News: One of the byproducts of writing this stupidly RUU blarticle was the emergence of the “DORK” acronym from the bad-person corner of my psyche. I’m giddy with excitement cuz now I can interchange usage of the venerable “DIC” acronym with “DORK” in my future ramblings. Whoo Hoo, a landmark event!
Accessing Configuration Data
Assume that on initialization, your C++ application reads in a bunch of configuration parameters from secondary storage prior to commencing its runtime mission. Via a trio of simple UML class diagrams, the figure below shows three ways (patterns?) to structure your application to read in and store configuration data for subsequent use by the program‘s productive, value added classes (user1, user2, etc).
In the first design, a singleton class is used to read and store the runtime configuration in RAM. The singleton can either be auto-instantiated at program load time in global/namespace memory before main() executes, or the first time it is accessed by one of the program’s user objects.
In the second approach, you employ a “ConfigOwner” class that encapsulates and owns the configuration data reader class (AppConfig). On program startup, the “ConfigOwner” object instantiates the “AppConfig” reader object and then subsequently passes a reference/pointer to it to all the user objects (which the “ConfigOwner” object doesn’t own).
In the third strategy, a higher level object (AppEncapsulator) owns all other objects in the application. On startup, this parent class is instantiated first. It fully controls the initialization sequence, creating the “AppConfig” object first and then pushing a reference/pointer to it down to its child User class objects when it subsequently constructs them.
Since the application startup sequence is centrally controlled, the third, parent-child approach is totally thread-safe. The implementation of the singleton approach, where the singleton is instantiated at program load time before main() starts executing, is also thread safe. The instantiation-on-first-access singleton approach and the ConfigOwner approach are subtlely thread unsafe without some clever synchronization coding added to ensure that the AppConfig object is fully constructed before it is accessed by its users.
Since I’m not fond of using singletons in situations where they’re not absolutely required (and this is arguably one of those cases, no?) and I disdain “clever” coding, I prefer the last, centrally controlled strategy. How about you? Are you clever, or a simpleton like me?
Note: Don’t mind the bracket turd on the right of the diagram. Since I’m a lazy ass and I try not to be a perfectionist when perfection is not needed, I left the pooper in rather than removing, fixing, and reinserting the graphic into the post. Too much work.
I’m The Right Guy At The Right Time
From a recent article (I forgot to bookmark the link – D’oh!) describing the large backlog of IPOs still scheduled for this year, I discovered that GM’s (supposed) resurrection is expected to be the largest. It’s estimated that the “Government Motors” IPO will raise $15B dollars, but none of it will come from me and you’ll understand why in the narrative that follows.
From the same article, I also learned that GM is being led by its fourth CEO in 18 months, Mr. Daniel Akerson. Guess what? Mr. Akerson is an aged and most probably out-of-touch white dude just like all the other recent esteemed GM CEOs. Guess what? Mr. Akerson also speaks in the same, self-centered, corpo tongue as most stereotypical Tayloristic CEOs:
I’m the right guy at the right time.
I’m looking out the front windshield.
GM’s products are second to none.
GM’s global manufacturing structure is the envy of the industry.
I did not get to where I am in life by being deaf, dumb, and blind.
I wish the company well, but, uh, I ain’t gonna invest in GM. Are you?
Assimilated And Digested
This is another one of my dorky pictures that doesn’t contain any accompanying words of explanation. “I’m a little verklempt, so talk amongst yourselves. I’ll give you a topic: Acquisition” – Linda Richman.
Thanx for the link dB!
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 