Archive
Idiomatic Idiot
Programming idioms are the language-specific, more concrete equivalent of design patterns. I remember watching a video interview with C++ creator Bjarne Stroustrup in which he recommended that programmers learn how to program idiomatically in 5, yes 5, different languages. WTF? I’ve been working in C++ for years now and it seemed like forever before I could comfortably program this way. There’s at least one whole book out there that teaches idiomatic programming in C++. Sheesh!
I think that to remain idiomatically competent in a language, one has got to work in the language almost daily for a long, sustained period of time. How can one do this with 5 languages? Maybe it’s just me – I am an Idiomatic Idiot.
How many languages could you confidently say you know how to program idiomatically in?
Access Change
To ensure consistency across our application component set in the team project that I’m currently working on, I’m required to inherit from a common base class that resides in a lower, infrastructure layer. However, since my class resides in the topmost, domain-specific layer of our stack, I want to discourage others from inheriting from it – but (as far as I know) there’s no simple way in C++ to do this (no contorted singletons please – it’s overkill).
In addition to inserting a /*we’ll fire you if you inherit from this class!*/ type comment and removing the virtual keyword from all overridden member functions, I recently discovered an additional, trivial way of discouraging others from inheriting from a class that is intended to be a leaf in an inheritance tree. It may already be an existing C++ idiom that I haven’t stumbled across, but I’ll call it “access change” just in case it isn’t.
The figure below shows what I mean by “access change“. As you can see in the Derived class, in addition to leaving the virtual keyword out of the Derived::mandatory() function definition, I also changed its access qualifier from protected to private.
What do you think? Are there any downsides to this technique? Are there any other “gentle” ways to discourage, but not prevent, other C++ programmers from deriving from a class you wrote that wasn’t intended to be used as a base class?
Three Ways
Oh crap! If you think my Rush Limbaugh-like, anti-hierarchical rants are over the top now, they may get “worse” moving forward. I just discovered a small, academic publisher in the U.K. that solely publishes books on alternatives to hierarchical org structures: Triarchy Press. Since books like these are either burned, shunned, or ignored by those they are intended to help, I hope they don’t go out of business.
Have you even ever heard of the “heterarchy” or “autonomous responsibility” alternatives to the hierarchy beast? If not, it shows how firmly entrenched the hierarchical mindset is in most people’s psyches, no?
In one of Triarchy Press’s flagship books, “The Three Ways Of Getting Things Done“, author Gerard Fairtlough postulates that some magic combo of the three legs of triarchy is the most economically efficient and socially redeeming way of achieving org goals.
Hierarchy is so entrenched that a complete replacement, if it does prove desirable, will take centuries. – Gerard Fairtlough
Hierarchy will never go away. Never! – Tom Peters
Culture Shift
In the video “Hacking Your Organization“, Lloyd Taylor states that low org productivity is often caused by a mismatch between explicit and implicit culture. When the espoused culture doesn’t align with the actual day-to-day operating culture of an org, people (because they’re not dumb asses) get disillusioned and turned off by the hypocrisy. Hence, it’s only natural that many people will “hang up the phone” and “disconnect & distance” themselves from their work and do what little they can to get by. Of course, the BM hypocrites responsible for keeping the implicit and explicit cultures unsynchronized judge these DICs as lazy under-performers. That’s because there’s no way that they, themselves, can be the catalyst of a disillusioned workforce. In their minds, they’re infallible and whatever they say about the culture is auto-magically true.
Mr. Taylor’s model, and he stresses that it’s just a model, partitions corpo cultures into four archetypes: communal, mercenary, networked, and fragmented. The criteria he uses to diagnose a culture are sociability and solidarity:
In Lloyd’s view, virtually all startups begin with vibrant communal cultures. As a company grows, because of the physical limitations of the human brain, a cultural shift has to occur at some point:
If, during growth, the company’s leaders don’t steer the org toward the culture that they want, or they hard-headedly maintain that their culture is still communal when a shift has occurred, then the implicit-explicit cultural mismatch that triggers low productivity will manifest. Bummer for all involved.
Mr. Taylor stresses that no culture is fully good or bad and that success can be sustained in all four culture types as long as the espoused culture is aligned with the actual culture – especially during cultural shifts. This is possible because each individual will know where they stand and what they need to do to become successful themselves. They can also decide whether they are comfortable operating in the org culture, and when to move on.
The hour long video is highly informative and Mr. Taylor uses all kinds of examples to bolster his theoretical views: Enron, Anderson Consulting, Lehman Brothers, Apple, Zappos.com, Hewlitt Packard, Oracle, etc. Hop on over to InfoQ and check it out if you’re interested in the fascinating topic of group culture.
The BCMT
Print out, copy, distribute, collect, and evaluate. If the results aren’t to your liking, ignore and bury them. Otherwise, toot your horn loudly and frequently.
Culture Convergence?
Many, many articles and books targeted at executives and senior managers spew out all kinds of elixirs, formulas, and lists guaranteed to catapult a business to the top of the heap. For example, take this squeaky clean and slightly redacted list from a book that will remain unnamed.
The one common, across the board demand that all these gurus impose on top leadership teams is that “you must change the culture“. The hidden assumption in these words is that one culture exists. Well, does it?…….
Maybe all these revered business gurus should talk about culture convergence instead of changing “the one culture“…..
How naive of me to think that there are two or more cultures in an org, no?
My Erlang Learning Status
Check out this slide from Erlang language co-designer Joe Armstrong’s InfoQ lecture: “Erlang – software for a concurrent world“. I’ve circled the features that have drawn me to Erlang because I’m currently developing product software where those qualities are hugely important to my customers. Despite their importance to success, they’re almost always given second class status by programmers and managers because they’re not domain-specific, “glamorous“, features.
The blue arrow is my sore spot. You see, I’ve been programming imperatively in FORTAN, then C, and then C++, since Jesus was born. Thus, learning the stateless, recursive, functional programming mindset that Erlang is founded upon is a huge hurdle for me to overcome. Nevertheless, as I’ve stated before, I’m half-assedly trying to learn OMOT how to program in Erlang with the aid of this very good book:
Here’s my learning “status” in terms of the book’s table of contents:
I don’t have an ironclad, micro-scheduled plan or BS risk register pinned on the wall in my war room, so I have no idea when I’ll be 100% done. But who knows, if I don’t abandon the effort:
Note: OMOT = On My Own Time
Look Ma, No Makeup!
From Livescribe dot-paper directly to blarticle, warts and all:
A Steady Drumbeat
In the context of getting a message to sink in, a wise and dear friend once told me: “it’s not a cymbal crash, it’s a steady drumbeat“. The reason this quote came to mind is because my blog dashboard says that I’ve published 607 posts to date and I was wondering how many of them were redundant – repeating the same message over and over again.
I have no freakin’ idea how many published posts seem redundant to you, but if they do, I’ll use that musical quote as the excuse for my narrow minded focus and lack of breadth. Plus, repetition is a powerful tool for brainwashing others into doing what you want them to do. Moooo Hah Hah!
The Wevo Approach
The figure below shows an example of a one-size-fits-all, waterfall schedule template that’s prevalent at many old school software companies. It sure looks nice, squeaky clean, and controllable, but as everyone knows, it’s always wrong. Out of fear or apathy, almost no one speaks out against this “best practice“, but those who do are quickly slapped down by the anointed controllers and meta-controllers of the project.
A more insidious, micro-grained, version of this waterboarding fiasco is shown below. It’s a self-medicating attempt to amplify the illusion of control that’s envisioned to take place throughout the execution of the project. Since schedules are concocted before an architecture or design has been reasonably sketched out and no one can possibly know up front what all the micro tasks are, let alone how long they’ll take (unless the project is to dig ditches), it’s monstrously wrong too. But shush, don’t say a word.
Once a monstrosity like this is baked into a huge Microsoft Project file or company proprietary scheduling document, those who conjured up the camouflage auto-become loathe to modify it, even as the situation dynamically changes during the death march. Once the project starts churning, new unforeseen “popup” tasks emerge and some pre-planned micro-tasks become obsolete. These events disconnect the schedule from reality quicker than you can say “WTF?“.
Moving on to a sunnier disposition, the template below shows a more “sane“, but not infallible, method of scheduling. It’s a model of the incremental “evo” strategy that I first stumbled upon from Tom Gilb – a bazillion years before the agile movement rose to prominence. In the evo(lutionary) approach, stable working software becomes visible early with each RDCT cycle and it grows and matures as the messy (it’s always messy) project lurches forward.
The figure below shows a tweaked version of the evo model. It’s a hybrid concoction of the waterboard and evolutionary development approaches – the “wevo“. Some upfront requirements and architecture exploration/definition/specification is performed by the elected team technical leaders before staffing up for the battle against the possibility of building a BBoM. The purpose of the upfront requirements and architecture efforts are to address major cross-cutting concerns and establish contextual boundaries – before letting the dogs loose.
Of course, the wevo approach is not enough. Another necessary but insufficient requirement is that the team leaders dive into the muck with the “coders” after the cross-cutting requirements and architecture definition activities have produced a stable, understandable blueprint. No jargon spewing software “rocketects” or “pure” software project leads allowed – everyone gets dirty – and for the duration.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 