Archive
Eeee-ewe, A Martini?
I love dirty martinis, but thank god (little “g” on purpose because I’m not fond of strict rules of behavior and BS dogma regarding a point source deity with a beard who looks like us) I only drink them on weekends – fer now (hee hee!). I used to hate the taste of DMs along with other hoytee- -toytee bourgeoisie (I’m not a communist – I swear!) drinks (e.g. manhattans, cosmos, rusty nails, etc), but a dear friend of mine for over twenty five years introduced them to me a coupla years ago.
Did this post have too many parentheses in it? If it did, it’s cuz I’m on my second dirty martini. If U check the date on this post, it’s a Sunday :^).
Charles (on the) Rocks
Charles Bukowski is on my long list of “to read” authors. What drew him to me is this awesome quote:
There was nothing really as glorious as a good beer shit—I mean after drinking twenty or twenty-five beers the night before. The odor of a beer shit like that spread all around and stayed for a good hour-and-a-half. It made you realize that you were really alive.
If you don’t bust a gut at that quote and this is your first foray into this ridiculous time wasting blog, please don’t ever come back here. No offense, but your time is too precious and there’s so much to explore/discover in this wonderful world that you shouldn’t be wasting it snorting my verbal diarrhea. Dude, wipe your nose cuz there’s a dingleberry hanging from it.
Some people never go crazy, What truly horrible lives they must live. – Charles Bukowski
Maker’s Schedule, Manager’s Schedule
I read this Paul Graham essay quite a while ago; Maker’s Schedule, Manager’s Schedule, and I’ve been wanting to blog about it ever since. Recently, it was referred to me by others at least twice, so the time has come to add my 2 cents.
In his aptly titled essay, Paul says this about a manager’s schedule:
The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.
Regarding the maker’s schedule, he writes:
But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started. When you’re operating on the maker’s schedule, meetings are a disaster.
When managers graduate from being a maker and morph into bozos (of which there are legions), they develop severe cases of ADHD and (incredibly,) they “forget” the implications of the maker-manager schedule difference. For these self-important dudes, it’s status and reporting meetings galore so that they can “stay on top” of things and lead their teams to victory. While telling their people that they need to become more efficient and productive to stay competitive, they shite in their own beds by constantly interrupting the makers to monitor status and determine schedule compliance. The sad thing is that when the unreasonable schedules they pull out of their asses inevitably slip, the only technique they know how to employ to get back on track is the ratcheting up of pressure to “meet schedule”. They’re bozos, so how can anyone expect anything different – like asking how they could personally help out or what obstacles they can help the makers overcome. Bummer.
Byzantine Labyrinth
During the birth and growth of dysfunctional CCHs, here is what happens:
- silos form and harden,
- a bewildering array of narrow specialist roles get continuously defined,
- layers of self-important and entitled RAPPERS emerge, and
- a byzantine labyrinth of processes and procedures are created by those in charge.
This not only happens under the “watchful eyes” of the head shed, but incredibly, those inside the shed-of-privilege are the chief proponents and instigators of all the added crap that slows down and frustrates the DICforce. Peter Drucker nailed it when he opined:
Ninety percent of what we call ‘management’ consists of making it difficult for people to get things done – Peter Drucker
On the other hand, T.S. Eliot also pegged it with:
“Half of the harm that is done in this world is due to people who want to feel important. They do not mean to do harm… They are absorbed in the endless struggle to think well of themselves.” – T. S. Eliot
Scalability: The Next Buzzword
Since I’m currently in the process of trying to help a team re-design an existing software-intensive system to be more scalable, the title of this book caught my eye:
It’s just my opinion (and you know what “they” say about opinions) but stay away from this stinker. All the authors want to do is to jump on the latest buzzword of “scalability” and make tons of money without helping anybody but themselves.
Check this self-serving advertisement out:
“The Art of Scalability addresses these issues by arming executives, engineering managers, engineers, and architects with models and approaches to scale their technology architectures, fix their processes, and structure their organizations to keep “scaling” problems from affecting their business and to fix these problems rapidly should they occur.”
Notice how they try to cover the entire hierarchical corpo gamut from bozo managers at the peak of the pyramid down to the dweebs in the cellar to maximize the return on their investment. Blech and hawk-tooey.
BTW, I actually did waste my time by reading the first BS chapter. The rest of the book my be a Godsend, but I’m not about to invest my time trying to figure out if it is.
Context Switching
“There is time enough for everything in the course of the day, if you do but one thing at once, but there is not time enough in the year, if you will do two things at a time.” – Lord Chesterfield (1740)
Study after study after study have shown that, due to the natural imperfections built into human memory, multitasking is inefficient and unproductive compared to single-tasking. The bottom line is that humans suck at multitasking. Unlike computers, when humans switch from doing one thought-intensive task to another, the clearing out of memory content from the current task and the restoration of memory content from the previous task greatly increases the chances of errors and mistakes being made.
So why do managers multitask all the time, and why do unenlightened companies put “multitasking prowess” on their performance review forms? Ironically, they do it to reinforce an illusion that multitasking is a key contributor of great productivity and accomplishment. When a “performance reviewer” sees the impressive list of superficial accomplishments that a multitasker has achieved and compares it to a measly list of one or two deep accomplishments from a single-tasker, an illusion of great productivity is cemented in the mind of the ignorant reviewer. Most managers, huge multitaskers themselves, and clueless to the detrimental effects of the malady on performance, tend to reward fellow multitaskers more than non-multitasking “slackers“. Bummer for all involved; especially the org as a whole.
The Rise Of The “ilities”
The title of this post should have been “The Rise Of Non-Functional Requirements“, but that sounds so much more gauche than the chosen title.
As software-centric systems get larger and necessarily more complex, they take commensurately more time to develop and build. Making poor up front architectural decisions on how to satisfy the cross-cutting non-functional requirements (scalability, distribute-ability, response-ability (latency), availability, usability, maintainability, evolvability, portability, secure-ability, etc.) imposed on the system is way more costly downstream than making bad up front decisions regarding localized, domain-specific functionality. To exacerbate the problem, the unglamorous “ilities” have been traditionally neglected and they’re typically hard to quantify and measure until the system is almost completely built. Adding fuel to the fire, many of the “ilities” conflict with each other (e.g. latency vs maintainability, usability vs. security). Optimizing one often marginalizes one or more others.
When a failure to meet one or more non-functional requirements is discovered, correcting the mistake(s) can, at best, consume a lot of time and money, and at worst, cause the project to crash and burn (the money’s gone, the time’s gone, and the damn thang don’t work). That’s because the mechanisms and structures used to meet the “ilities” requirements cut globally across the entire system and they’re pervasively weaved into the fabric of the product.
If you’re a software engineer trying to grow past the coding and design patterns phases of your profession, self-educating yourself on the techniques, methods, and COTS technologies (stay away from homegrown crap – including your own) that effectively tackle the highest priority “ilities” in your product domain and industry should be high on your list of priorities.
Because of the ubiquitous propensity of managers to obsess on short term results and avoid changing their mindsets while simultaneously calling for everyone else to change theirs, it’s highly likely that your employer doesn’t understand and appreciate the far reaching effects of hosing up the “ilities” during the front end design effort (the new age agile crowd doesn’t help very much here either). It’s equally likely that your employer ain’t gonna train you to learn how to confront the growing “ilities” menace.
Just The Facts Ma’am
The other day, I had a confrontation with an anointed leader. (Being the insensitive and self-righteous jerk that I am, and supposedly incapable of being a leader myself, that happens a lot). After I made some normally “undiscussable” assertions as to the poor leadership behavior (more like NO leadership behavior) being exhibited by my confrontee, he/she accused me of not having all the facts. My counter was, “You’re absolutely right, but when does anyone have ALL the facts before they make a judgment regarding a FUBAR situation or a person’s behavior?“.
How does one know when ALL the facts have been discovered? Is there such a thing as ALL the facts? Even if ALL the facts can be unearthed, is it a foregone conclusion that every fact will always interpreted the same way by all people? Can words or, for the fellow engineers in the house, equations convey any universal truth, or are they just approximations?
Obfuscators And Complexifiers
Since I’m pretty unsuccessful at it, one of my pet peeves is having to deal with obfuscators and complexifiers (OAC). People who chronically exhibit these behaviors serve as formidable obstacles to progress by preventing the right info from getting to the right people at the right time. “They” do so either because they’re innocently ignorant or because they’re purposefully trying to camouflage their lack of understanding on the topic of discussion for fear of “looking bad”. I have compassion for the former, but great disdain for the latter – blech!
The condundrum is, in CCH corpocracies, there’s an unwritten law that says DICs aren’t “allowed” to publicly expose purposeful OACs if the perpetrators are above a certain untouchable rank in the infallible corpo command chain. In extremely dysfunctional mediocracies, no one is allowed to call any purposeful OAC out onto the mat, regardless of where the dolt is located in the tribal caste system. In either case, retribution for the blasphemous transgression is always swift, effective, and everlasting. Bummer.
Unscalable Orgs
My friend Byron Davies sent me a link to this 3 minute MIT Media Lab video in which associate Media Lab Director Andy Lippman challenges us to recognize four common flaws plaguing all of our institutions. Obtaining a new awareness and understanding of the plague is the first step toward meaningful redesign.
According to Lippman, the top four reasons for organizational decline are:
- They’re out of scale – they’ve grown too big to perform in accordance with their original design
- They’re monocultures – they all act the same
- They’re opaque – nobody from within or without understands how they freakin’ work
- They’ve lost their original mission – A summation of the previous three reasons.
Because of the pervasive institutional obsession for growth, Lippman seems to think that solving the scaling problem through the development of nested communities is the most promising strategy for halting the decline.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 