Archive
Simply Notice…
I’ve been following Leo Babauta, the creator of ZenHabits.net, for several years. Check out his inspirational story of personal transformation here: “About Leo“. In a recent Zen Habits newsletter, guest poster Gail Brenner suggested the following minimalist guide to inner peace:
This list recently came to mind while I was reading some complicated and messy library code in order to understand how to incorporate its functionality into my own code mess. Surprise! The source code was too dense and it required a deeper mental stack than the shallow one in my head, so I did what I usually do in those situations – I started getting pissed off. D’oh! Then, out of nowhere, step #2 in Gail’s list came to mind. I won’t answer the questions posed in the step, but you can imagine that they weren’t positive.
So, what did I do next? I briefly looked at step 3 and then I careened off course. I went out to stalk the library code author with the intent of ripping him/her a new one. Hah, just joking! What I really did was this. I stepped back from the hundreds of lines of source code and I reverse engineered a simpler, abstracted class diagram of the mess. By distancing myself from the code and using the more abstract class diagram to understand the code, I came to the same conclusion – it was a freakin’ mess. D’oh!
Are you wondering what my next step was? I ain’t tellin’.
Yahoo! Boohoo!
Unless you were born yesterday, you’ve probably heard about the death spiral that former internet great Yahoo! has commenced. In this blarticle from TechCrunch, “Former Yahoo Engineers Shed Light On Why Delicious And Other Acquisitions Failed“, a couple of quotes from former employees brought a tear to my eye.
…it does provide a picture of a company that bogged its acquired-startups down in its company’s administrative BS. As Chad Dickerson, former Yahoo developer evangelist and the current CTO of Etsy comments, “In my experience, entrepreneurs moving into Yahoo! often got stuck doing PowerPoints about “strategy” instead of writing code and shipping products.”
Elliott-McCrea writes: I recently pulled up a worklog I was keeping in 2008-2009, and I found 18 meetings scheduled over a 9 month period discussing why Flickr’s API was poorly designed and when we’d be shutting it down and migrating it to the YOS Web Services Standard.
What I’d like to know is: “Did any of the layers of corpo honchos have any conscious clue that the patriarchical and bureaucratic monster they brought to life was killing the golden goose?” What do you think?
Leader Or Dictator?
After reading Chetan Dhruve’s “Why Your Boss Is Programmed To Be A Dictator“, I’ve had a change of heart. I’ve concluded that hierarchy is a symptom and not the dominant cause of dysfunctional corpricracies. In his book, Mr. Dhruve skillfully develops a compelling case that the lack of the right to vote managers into and out of higher status slots in the hierarchy is the real cause of poor org-wide performance and DIC-force suffering in the workplace.
Mr. Dhruve asserts that there are two canonical forms of power systems: leaderships and dictatorships. By his definition, leaders are elected into power by those they lead, and dictators assume power by any other means. In corpricracies, dictators don’t assume power by shedding blood, they assume power in a civilized manner; by anointment from higher status dictators.
The unquestioned assumption in dictatorships is that superior status equates directly with superior knowledge and judgment. In corpo dictatorships, un-submissive subjects aren’t killed. They’re marginalized at best, and fired at worst. Chetan closes his masterpiece with a brilliant quote targeted at anyone in any power structure:
If you aren’t elected, you’re a dictator – Chetan Dhruve
Quote Mangling
I love quotes because they pack a lot of energy into small packages without requiring a long winded and jargon filled explanation. I also like extending quotes to give another take on the wisdom imparted by the original text because I’ve learned to never believe anything 100 percent; including my own twisted and anguished thoughts. Here are some snarky Bulldozer00 quote enhancements:
- “When the going gets tough, the tough get going – right out the door with the cash.” (English proverb + Bulldozer00)
- “I don’t know the key to success, but the key to failure is trying to please everybody – another key to failure is trying to piss everybody off.” (Bill Cosby + Bulldozer00)
- “A lot of people mistake unnecessary complexity for sophistication – and those people are usually managers.” (Dan Ward + Bulldozer00)
- “If you are indispensable, you’re unpromotable – but at least you know how to directly create value.” (Unknown + Bulldozer00)
- “I love deadlines because I like the whooshing sound they make as they fly by – and the angst they instill in the managers who dictated them.” (Doug Adams + Bulldozer00)
- “Multitasking is not for serious work – it’s for managerial make-work.” (Bjarne Stroustrup + Bulldozer00)
- “I believe that there is such a thing as objective truth, but a lot of people have an objective truth that differs from mine – and those people are wrong.” (Cynthia Tucker+ Bulldozer00)
- “Debugging is like farting, it’s not so bad when it’s your own code – except when you crap your pants.” (Unknown + Bulldozer00)
- “What we need is more people to lose their temper in public – unless people in power are in the vicinity.” – (Watts Wacker + Bulldozer00)
- “The point of quotations is that one can use another’s words to be insulting – D’oh! and WTF?.” – (Amanda Cross+ Homer Simpson + Bulldozer00)
What quotes would you like to extend?
Monitoring And Learning
Courtesy of this Scott Berkun retweet,
I latched onto this Harvard Business School paper abstract:
Even though the paper is laced with impeccable math and densely “irrefutable” logic, the conclusion of “looser monitoring -> more learning -> more creativity & innovation” seems intuitively obvious, doesn’t it?
Assume that the top leaders in your org embrace the idea and sincerely want to put it into action to detach the group from the status quo and propel it toward excellence. Well, fuggedaboutit. The scores of mediocre middle managers within the institution who do the monitoring will instantaneously switch into passive-aggressive mode and thwart any attempt to institute the policy. They’ll do this because it will most likely expose the fact that they are not only suppressing creativity and innovation where the rubber hits the road, but they are not adding much value to the operation themselves. How do I know this? Because that’s what I’d feel culturally forced to do. But not you, right?
New DDS Vendors
Since I’m a fan of the DDS (Data Distribution Service) inter-process communication infrastructure for distributed systems, I try to keep up with developments in the DDS space. Via an Angelo Corsaro slideshare presentation, I discovered two relatively new commercial vendors of the high performance, low latency, OMG! messaging standard: Twin Oaks Computing and Gallium Visual Systems. I don’t know how long the newcomers have been pitching their DDS implementations or how mature their products are, but I’ll be learning more about them in the weeks to come.
Last week, the four DDS vendors got together at the OMG DDS meeting in CA and they collaboratively executed 9 distributed system test scenarios to highlight the interoperability of the vendors’ products. The Angelo Corsaro slide snippets below show the conceptual context and the goals of the event.
The VP of marketing at RTI, Dave Barnett, published a short video showing that the demo was a success: DDS Interoperability Demo. Since I’m a distributed, real-time software developer geek, this stuff makes me giddy with enthusiasm. Sad, no?
Bugs Or Cash
Assume that you have a system to build and a qualified team available to do the job. How can you increase the chance that you’ll build an elegant and durable money maker and not a money sink that may put you out of business.
The figure below shows one way to fail. It’s the well worn and oft repeated ready-fire-aim strategy. You blast the team at the project and hope for the best via the buzz phrase of the day – “emergent design“.
On the other hand, the figure below shows a necessary but not sufficient approach to success: design-allocate-coordinate. BTW, the blue stick dude at the center, not the top, of the project is you.
Nuff said?
Small, Loose, Big, Tight
This Tom DeMarco slide from his pitch at the Software Executive Summit caused me to stop and think (Uh oh!):
I find it ironic (and true) that when man-made system are composed of “large pieces tightly joined“, they, unlike natural systems of the same ilk, are brittle and fault-intolerant. Look at the man-made financial system and what happened during the financial meltdown. Since the large institutional components were tightly coupled, the system collapsed like dominoes when a problem arose. Injecting the system with capital has ameliorated the problem, but only the future will tell if the problem was dissolved. I suspect not. Since the structure, the players, and the behavior of the monolithic system have remained intact, it’s back to business as usual.
Similarly, as experienced professionals will confirm, man made software systems composed of “large pieces tightly joined” are fragile and fault-intolerant too. These contraptions often disintegrate before being placed into operation. The time is gone, the money is gone, and the damn thing don’t work. I hate when that happens.
On the other hand, look at the glorious human body composed of “large pieces tightly joined“. It’s natural, built-in robustness and tolerance to faults is unmatched by anything man-made. You can survive and still prosper with the loss of an eye, a kidney, a leg, and a host of other (but not all) parts. IMHO, the difference is that in natural systems, the purposes of the parts and the whole are in continuous, cooperative alignment.
When the individual purposes of a system’s parts become unaligned, let alone unaligned with the purpose of the whole as often happens in man made socio-technical systems when everyone is out for themselves, it’s just a matter of time before an internal or external disturbance brings the monstrosity down to its knees. D’oh!
Inter-Thread Message Communication
When the asynchronously executing threads in a multi-threaded application process need to communicate with each other using same-address-space messages, a thread-safe way of providing a message passing service is required. The figure below shows a black, um, yellow box model of the functionality that needs to be designed, coded, and tested for solving the problem. The little ovals with arrow thingies on them represent asynchronously executing threads of code either on the same cpu or on separate cpus. The little lock thingy represents a mutex that protects the mechanism internals from data corruption via simultaneous, uncontrolled access by more than one thread (I hate when that happens!).
There are at least two ways to implement a thread-safe, inter-thread message passing service; by passing copies of the message objects themselves or by passing (smaller) pointers to message objects. As the figures in the models below illustrate, the design and user API for the pass-by-objects approach is simpler than the pass-by-pointers approach. The tradeoff is that the performance of the pass-by-objects approach degrades as the message size gets larger. In addition, passing by pointer allows dynamic polymorphism to be utilized.
Option 1: Pass-By-Objects
Option 2: Pass-By-Pointers (a.k.a references)
Since, in option 2, the memory that holds the message content is managed by the mutex-protected message passing mechanism and not shared by the clients themselves, the clients must acquire a pointer to a message memory buffer before either filling (writer) or processing (reader) the payload. Thus, the mutex must be locked/unlocked twice; once to “pop” the pointer and a second time to “push” the pointer.
An alternative to the double queue design in option 2 is to require the clients to manage the message buffers themselves via the aid of a memory pool. The disadvantage of pushing the message memory management out of the queuing mechanism and up into the application layer is that it introduces a long distance coupling between the Writer and Reader – which may be written by different people. If the reader programmer forgets to release a pointer back to the pool after processing a message, a memory leak will occur (I hate when that happens!). By encapsulating the lock/unlock actions within the message passing mechanism written by one person, the chances of introducing a memory leak are reduced and the reader and writer threads remain decoupled.
A third inter-thread message passing design option is to employ a (much trickier to implement) lockless mechanism. Better yet, the use of a programming language that natively supports inter-thread message passing under the covers unburdens application programmers with the subtleties of inter-thread synchronization.
Don’t You Wish….
…you can have a Dilbertonian conversation with a BM (past or present) like the one below without getting fired? Of course, the elegant genius of Dilbert is that former cubicle-dweller-turned-gazillionaire Scott Adams makes you want to laugh and cry simultaneously.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 