Archive
Executive Misnomer
I don’t know why the dudes at the top of the corpo food chain are called “executives”. They don’t execute anything except non-conformers. They coerce and patronize others into bidding their will – which is to make themselves rich regardless of the performance of their orgs.
- CEO = Chief Evisceration Officer
- COO = Chief Oppression Officer.
- CTO = Chief Torture Officer
Sycophant compensation committees reinforce the ubiquitous make-me-rich executive process by striving to pay execs as much as they can (to retain top “talent”) while striving to pay the DICforce as little as possible (to keep fixed costs down).
Cucumbers, Pickles, Brine
It’s been a while since I read Gerry Weinberg’s “Secrets Of Consulting“, but the cucumber-pickle-brine story has been frequently appearing (uninvited, of course) in my mind. It goes something like this:
No matter how vehemently a cucumber says he/she will not turn into a pickle if dropped into a barrel of pickles filled with brine, he/she will get pickled. No exceptions.
When a DIC crosses the magical threshold into the land of privilege, the guild of management, the cucumber-to-pickle transformation is inevitable. From lowly wealth creator to status taker, schedule jockey, planner, watcher, controller, evaluator. Trouble is, most cucumbers want to get pickled.
Ornament And Substance
When you’re forced to be simple, you’re forced to face the real problem. When you can’t deliver ornament, you have to deliver substance. – Paul Graham (Hackers And Painters)
Mr. Graham’s quote explains why the higher one goes up in the corpo chain of command, the more jargon-filled and superficial the communications bestowed upon the adoring DICforce below. This ornament/substance conundrum is also true for DIC to DIC communication when one DIC is a highly credentialed complexifier and obfuscator. You see, when people don’t know what they’re freakin’ talkin about and they feel the egoic need to appear infallible and all-knowing, they’re compelled to cover it up by attempting to make others feel inferior and dumb.
Alas, don’t lose your faith in humanity because it’s not the individual ornament-deliverers that are “bad”. It’s the ancient pyramidal class system that they’re an integral cog in that weaves that behavior into the fabric of their being. Because the ornament/substance dichotomy is a blind spot to them and the system automatically provides them with power and riches (at the expense of the whole), the system’s designers and maintainers have no incentive to blow up and redesign the system for optimal performance of the whole. Plus, virtually every other corpricracy is structured as a CCH, so it must be right, no?
Pompous?
In “Hackers And Painters“, Paul Graham writes:
Beginning writers adopt a pompous tone that doesn’t sound anything like the way they speak.
Hmmm. When I read that, I thought “Does this quote apply to me?“. Since I’m embedded within the system of interest here, (which is me, me, me, of course!) and not an external observer, I’m not qualified to answer the question. There’s one person that I interact with almost daily that I know reads this blog semi-regularly. If he’s reading the post, could he please profer his opinion?
High Level Doers
Jim Goodnight, (CEO of the SAS Institute, Inc), writes code on the side: “His first love is programming, which he likens to solving puzzles“. Marissa Meyer (Vice President, Search Products & User Experience, Google, Inc.) writes code on the side:
I still like to write some programs every year. I do some programming on the weekends. Lately it’s been more web-centric, using PHP and MySQL. The next thing I’ll try to tackle is the Google App Engine. I’m looking to do a little more programming with Python and Ruby on Rails. But I think it’s just an element of keeping my skills fresh by exploring some of these new trends and keeping my hand in coding, even if it’s on the side of core Google work. – From the book “Making It Big In Software“
Gee, do you think this low level behavior by high level employees has anything to do with why these two companies are considered insanely great by boatloads of experts and laymen? How about your company? Forget about those in the stratosphere like Jim and Marissa, do any of your front line managers do any grunge work “on the side” to keep themselves grounded in reality? Probably not, because when they made the leap into the guild of management they became too self-important for such mundane activity. Plus, because they’re expected to be infallible, they can’t be “seen” making any mistakes by the DICforce.
Emergent Design
I’m somewhat onboard with the agile community’s concept of “emergent design“. But like all techniques/heuristics/rules-of-thumb/idioms, context is everything. In the “emergent design” approach, you start writing code and, via a serendipitous, rapid, high frequency, mistake-making, error-correction process, a good design emerges from the womb – voila! This technique has worked well for me on “small” designs within an already-established architecture, but it is not scalable to global design, new architecture, or cross-cutting system functionality. For these types of efforts, “emergent modeling” may be a more appropriate approach. If you believe this, then you must make the effort to learn how to model, write (or preferably draw) it up, and iterate on it much like you do with writing code. But wait, you don’t do, or ever plan to do, documentation, right? Your code is so self-expressive that you don’t even need to comment it, let alone write external documentation. That crap is for lowly English majors.
To religiously embrace “emergent design” and eschew modeling/documentation for big design efforts is to invite downstream disaster and massive post delivery stakeholder damage. Beware because one of those downstream stakeholders may be you.
Approver To Approvee Ratio
Every non-trivially sized profit-making organization has a number of approvers and approvees. For approvees to be enabled to do anything of significance like, uh, create products and respond to customers, they need the blessing of one or more approvers. As the graph below implies, it’s the “or more” word duo in the previous sentence that has an ominous connotation.
As the AAR in a group of people organized for a purpose increases, the org’s CPERF will start declining at some point in time. At a mystical value of “K”, the point of no return is reached and it’s all down hill from there. As the K threshold is exceeded, the maze of approver signatures that an approvee needs to navigate becomes untenable and the responsiveness of the “system” goes down the crapper. Even worse, the lower class approvee subgroup soon jettisons its sense of initiative and only assaults the approver fortress when a high ranking approver him/herself forces the action.
In clueless corpricracies, no one diligently watches over the AAR and prevents it from exceeding K. Quite the contrary, approvers love to hire more approvers because they have much in common with them and they love to have other approvers report to them – so they can approve the underling approver’s future requests for approval.
Approve, approve, approve your request, gently up the chain.
Sourly, sourly, sourly, sourly, work is but a drain.
How Many Tines….
…does a fork have? Hoytee-toytee forks have three, and regular-people forks have four. On a totally different plane of thought, how many tines have you considered taking decisive action on something that really mattered to you but decided not to because of your fear of “what other people (especially the hoytee-toytee dudes with authority over you) would think“? Even worse, how many tines have you not taken action on something important to you, but you didn’t know you remained inert because you weren’t aware of your subconscious tendency to submit to authority? Obviously, you couldn’t count how many tines you did this because if you weren’t aware, you wouldn’t have any freakin’ idea of when to increment your counter.
It is only by risking our persons from one hour to another that we live at all.”- William James
PAYGO II
PAYGO stands for “Pay As You Go“. It’s the name of the personal process that I use to create or maintain software. There are five operational states in PAYGO:
- Design A Little
- Code A Little
- Test A Little
- Document A Little
- Done For Now
Yes, the fourth state is called “Document A Little“, and it’s a first class citizen in the PAYGO process. Whatever process you use, if some sort of documentation activity is not an integral part of it, then you might be an incomplete and one dimensional engineer, no?
“…documentation is a love letter that you write to your future self.” – Damian Conway
The UML state transition diagram below models the PAYGO states of operation along with the transitions between them. Even though the diagram indicates that the initial entry into the cyclical and iterative PAYGO process lands on the “Design A Little” state of activity, any state can be the point of entry into the process. Once you’re immersed in the process, you don’t kick out into the “Done For Now” state until your first successful product handoff occurs. Here, successful means that the receiver of your work, be it an end user or a tester or another programmer, is happy with the result. How do you know when that is the case? Simply ask the receiver.
Notice the plethora of transition arcs in the diagram (the green ones are intended to annotate feedback learning loops as opposed to sequential forward movements). Any state can transition into any other state and there is no fixed, well defined set of conditions that need to be satisfied before making any state-to-state leap. The process is fully under your control and you freely choose to move from state to state as “God” (for lack of a better word) uses you as an instrument of creation. If clueless STSJ PWCE BMs issue mindless commands from on high like “pens down” and “no more bug fixing, you’re only allowed to write new code“, you fake it as best you can to avoid punishment and you go where your spirit takes you. If you get caught faking it and get fired, then uh….. soothe your conscience by blaming me.
The following quote in “The C++ Programming Language” by mentor-from-afar Bjarne Stroustrup triggered this blog post:
In the early years, there was no C++ paper design; design, documentation, and implementation went on simultaneously. There was no “C++ project” either, or a “C++ design committee.” Throughout, C++ evolved to cope with problems encountered by users and as a result of discussions between my friends, my colleagues, and me. – Bjarne Stroustrup
When I read it on my Nth excursion through the book (you’ve made multiple trips through the BS book too, no?), it occurred to me that my man Bjarne uses PAYGO too.
Say STFU to all the mindlessly mechanistic processes from highly-credentialed and well-intentioned luminaries like Watts Humphrey’s PSP (because he wants to transform you into an accountant) and your mandated committee corpo process group (because the chances are that the dudes who wrote the process manuals haven’t written software in decades) and the TDD know-it-alls. Embrace what you discover is the best personal development process for you; be it PAYGO or whatever personal process the universe compels you to embrace. Out of curiosity, what process do you use?
If you’re interested in a higher level overview of the personal PAYGO process in the context of other development processes, you can check out this previous post: PAYGO I. And thanks for listening.
Survive And Prosper
The purpose of a living system is to survive and prosper. There are different levels of systems. For example, there’s the organization, the organizational unit, the organizational group, and the organizational worker. Each of these human-composed entities can be considered a System Of Interest (SOI) unto itself and, as the figure below shows, SOIs are nested and connected.
If you believe my BS assertion that the purpose of a SOI is to survive and prosper, then each SOI may (and almost always does) choose to do whatever it can to survive, regardless of the cost to other internally nested and externally coupled systems. Of course, since everything is connected, the actions chosen by one “subsystem” to optimize its survival can (and almost always does) degrade the survival chances of those subsystems nested within it and those systems in which it is nested. For example, if a Bureaucratic Overhead Org Group (BOOG) like “purchasing” puts a boatload of Draconian procedures and forms and approval barriers in place to show how “important” they are, they degrade corpo performance by hindering timely acquisition of external equipment and services needed to get the job done. Schedules slip, which means customers aren’t delighted, and the people in other SOIs think twice about ordering tools that could make them more efficient and happy.
The dysfunction is even worse than you think. When a member of another SOI tries to point out the inefficiency of a BOOG to the so-called BOOG Leader (BOOGL), the auto-defense instinct kicks into high gear. Clever BOOGLs (and they must be clever because they got themselves appointed as a BOOGL in the first place) twist the situation out of whack. The instigator and his/her native SOI are made out to be the cause of inefficiency in the BOOG. This is done, of course, so that the BOOGL and his/her BOOG can survive and prosper. It’s so sad that ya gotta laugh…… LOL!
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 