Archive
Rules, Exceptions, Guidelines
Unlike natural laws (on the macroscopic level) which unremorsefully allow no exceptions, I think all human concocted rules should be flexible to exceptions, no? If you believe that, then maybe the word “rule” should be replaced with “guideline”. Doing this can be interpreted as splitting hairs, but I think it may positively affect those who are required to operate by the “rules”. It shows respect and implies that some freedom is allowed to continuously improve things. Since the yearning for freedom is built into the fiber of every human being, those in positions of authority who conjure up the “rules” should take heed.
Note: The model above is a UML “class diagram”, which is used to depict the static structure of a system. Other UML diagrams can be used to model the behaviors of a system. The diagram can be interpreted as follows:
- A bureaucracy has NUM_BMS BMs and NUM_DICS DICs and a Rule Book.
- The BMs make the rule book, which has NUM_RULES (usually a boatload) rules.
- The DICs are obliged to follow the rules, written or unwritten (but understood) – or else.
Monolithic Redesign
On my latest assignment, I have to reverse engineer and understand a large monolithic block of computationally intense, single-threaded product code that’s been feature-enhanced and bug-fixed many times, by many people, over many years (sound familiar?). In addition to the piled on new features, a boatload of nested if-else structures has been injected into the multi-K SLOC code base over the years to handle special and weird cases observed and reported in from the field.
As you can guess, it’s no one’s fault that the code is a tangled mess. It’s because the second law of thermodynamics has been in action doing its dirty work destroying the system without being periodically harnessed by scheduled acts of husbandry. A handful of maintenance developers imbued with a sense of personal responsibility and ownership have tried their best to refactor the beast into submission; under the radar.
Because the code is CPU intensive and single threaded, it’s not scalable to higher input data rates and its viability has hit “the wall”. Thus, besides refactoring the existing functionality into a more maintainable design, I have to simultaneously morph the mess into a multi-threaded structure that can transparently leverage the increased CPU power supplied by multicore hardware.
Note that redesigning for distributed flexibility and higher throughput doesn’t come for free. Essential complexity is added and additional latency is incurred because each input sample must traverse the 3 thread pipeline.
Piece of cake, no? Since lowly “programmers” are interchangeable, anyone could do it, right? I love this job and I’m having a blast!
Making A Living
In “Stewardship: Choosing Service Over Self-Interest“, Peter Block comically states:
No one should be able to make a living simply planning, watching, controlling, or evaluating the actions of others.
If corpo granite heads everywhere took that statement to heart (which they can’t, and thus won’t), they’d eliminate themselves and all the layers below them in an instant – poof! Alas, that ain’t gonna happen cuz someone’s gotta look pretty, run the show, and suck up the dough. Seriously, someone really does have to run the show to keep the CCF viable.
Actually, the dudes in the penthouse have others do the PWCE dirty work for them. The thugs in middle management and the pure overhead departments like Human Resources, Quality Assurance, Configuration Management, and Accounting serve nicely as the lower level sensors, alarm detectors, and actuators in the system. Because of this sleight of hand, the DICforce often targets their ire at those “support” functions and not where it rightfully ought to be targeted – the high priests living it up in the self-congratulatory head shed.
C++ Naming Conventions
For grins, I perused a few books written by several C++ mentors that I respect and admire. I was interested in the naming conventions that they personally use when writing code. Here are the results.
Scott Meyers (Effective C++):
class names – class PhoneBook {};
member function names – void addPhoneNumber(const std::string& pn);
member attribute names – std::string theAddress;
Note: no annotation to distinguish class member attributes from local function variables.
Bjarne Stroustrup (The C++ Programming Language):
“I consider the CamelCodingStyle of identifiers “pug ugly” and strongly prefer underscore_style as cleaner and inherently more readable, and many people agree. On the other hand, many reasonable people disagree.“
class names – class Phone_book {};
member function names – void add_phone_number(const std::string& pn);
member attribute names – std::string the_address;
Note: no annotation to distinguish class member attributes from local function variables.
Herb Sutter and Andrei Alexandrescu (C++ Coding Standards):
class names – class PhoneBook {};
member function names – void AddPhoneNumber(const std::string& pn);
member attribute names – std::string theAddress_;
Note: they use post-underscores to distinguish class member attributes from local function variables (int clientName_; //is a class member)
When I’m not constrained by a specific naming standard, I use this one:
class names – class PhoneBook {};
member function names – void add_phone_number(const std::string& pn);
member attribute names – std::string the_address_;
Note: Like Herb & Andrei, I use post-underscores to distinguish class member attributes from local function variables (int client_name_; //is a class member).
Spreading Happiness
Just like last year, as soon as I heard that Zappos.com’s 2009 culture book was available, I e-mailed the company to get one. Just like last year, I received my free, postage paid copy in the mail three days later. What a great way to spread happiness, no?
Right on page number 1, Zappos CEO Tony Hsieh states:
People may not remember exactly what you did or what you said, but they will always remember how you made them feel.
Who says there is no room in business for emotions? Ninety-nine percent of business schools and business executives do, that’s who: “It’s not personal, it’s business.” Over the years I’ve learned to question the assumptions that institutional bozeltines, oops, leaders operate under. Sadly, I’ve discovered that most of those taken-for-granted, 100 year old assumptions like “the separation of feeling from work” don’t hold true anymore. How about you?
Leverage Points
In Places to Intervene in a System, systems thinker Donella Meadows lists the following 9 leverage points for keeping a system “on the rails” and in continuous pursuit of its goals.
9. Numbers (subsidies, taxes, standards).
8. Material stocks and flows.
7. Regulating negative feedback loops.
6. Driving positive feedback loops.
5. Information flows.
4. The rules of the system (incentives, punishment, constraints).
3. The power of self-organization.
2. The goals of the system.
1. The mindset or paradigm out of which the goals, rules, feedback structure arise.
The items are listed in increasing order of difficulty. Of particular interest is number 1, the “mindset” of the system controller(s). In so-called “modern” corpricracies, the patriarchical mindset of “we’re in charge and we know what’s best, so STFU and do what you’re told“, has ruled the day since the Henry Ford era. In that day, since the typical workforce was under-educated and managers actually knew how to perform and teach the work that kept a company viable, patriarchy worked well. These days, since the situation has changed (and continues to change) immensely, patriarchy can drive a company into the ground.
When managers don’t have a clue how to do the work, they ignore problems, issues, and ideas floated up from the bottom by the DICforce. This crucial feedback loop for sustained viability gets severed and the org suffers greatly for it. BMs collectively, and often unconsciously, behave this way in order not to look stupid and preserve their aura of infallible superiority. Ideas that can save six or seven figures in costs and product enhancements that may increase competitiveness go un-investigated or are killed via “it’s not in the budget”.
Maybe surprisingly to some, the vast majority of the DICforce actually buys into the patriarchical mindset because that’s the way it’s been for eons. DICs that initially don’t buy into patriarchy fall in line as soon as they are ignored or are slapped down a couple of times. Those that continue to buck the patriarchy after being “warned” are shackled or expelled for “insubordination” – another great term that reinforces the patriarchical mindset.
Closed Systems
In “Entropy Demystified“, Arieh Ben-Naim states an often forgotten fact about entropy:
The entropy of a system can decrease when that system is coupled with another system (e.g. a heating system connected with a thermostat). The law of ever increasing entropy is only valid in an isolated system.
In the figure below, the system on the left is coupled with the external environment and its members can use the coupling to learn how to adapt, dynamically self-organize, and arrest the growth in entropy that can destroy systems. In the isolated system on the right, which models a typical corpo mediocracy run by fat headed and infallible BMs who ignore everything outside their cathedral walls, there is no possibility of learning – and entropy marches forward.
Sacrifice Or Enjoyment?
On the recommendation of Fred Brooks, I read Dorothy Sayers’s “The Mind Of The Maker” after finishing his delightful “The Design Of Design“. TMOTM explores the possible connections and similarities between human and divine creativity. This passage triggered a twinge of gratitude within me.
When a job is undertaken from necessity, or from a grim sense of disagreeable duty, the worker is self-consciously aware of the toils and pains he undergoes, and will say: “I have made such and such sacrifice for this.” But when the job is a labor of love, the sacrifices will present themselves to the worker – strange as it may seem – in the guise of enjoyment. – Dorothy Sayers
Why gratitude? Because I’ve been lucky, incredibly lucky, to have worked on enjoyable projects doing work I love for the vast majority of my career. Oh sure, there were temporary spikes of perceived “poor me” thinking on each and every one of those projects, but at end game, I felt like I contributed something of value while enjoying the work at the same time. I think, but am not sure, that most people can’t quite say that. Some people hate to go to their jobs every single day.
Sayers is an eloquent writer and there’s quite a bit of good stuff in TMOTM, but I felt my mind wandering often. I was too turned off by the religious-specific passages and references. Nevertheless, here are a few other gems that kept me reading till the end of the book:
Every thought is an inseparable trinity of memory, understanding, and will.
The stronger the creative pulse, the more powerful is the urge away from any identification of the ego with creation.
The artist does not see life as a problem to be solved, but as a medium for creation.
From Searcher To Explorer
Most spiritual teachers advise students to “stop the search!”. Like many other frustrated spiritual aspirants, I don’t know of any other strategy for attaining enlightenment, an awakening, inner peace, relief from suffering, separation from ego, or whatever you want to call it.
To me, “searching” means looking for something specific, like lost keys or oil. Since I don’t have a freakin’ clue as to what “enlightenment” is and I do want to follow the advice of those who purportedly have dissolved the ego (or at least have rid themselves of ego-dominance), I’ve stopped being a searcher. As of today, I’m now (drum roll please) an explorer! Since exploring means probing and sensing for the new and unknown, that’s what I will do from now on.
OK, OK, back to reality. This post is just another self-delusional attempt to fill a new bottle with the same old wine, err, vinegar. Ergo, on with the search!
Jumpin’ Out
If you’re deeply embedded in a complex social system, it’s incredibly difficult to gain any insight into what the system you’re enmeshed in really does, or how it does what it does. Even though you’re an integral element of the system, your view is most likely obscured by your lack of interest in finding out or, more likely, by a lack of communication from the dudes in the penthouse. All you can see are trees. No forest, and no sun above the treetops.
A great way of “jumping out of the system” to get a better view and understanding is by modeling. By taking a stab at modeling the static structures and dynamic behaviors of the system you’re in, you can get a much better feel for what’s going on.
A formal language like UML or SysML paired with a good visual drawing tool like Visio can be a powerful tool set to help you gain perspective, but all you really need is a pencil and paper to start things off. Since your first few iterations will suck and be totally wrong, you’ll be throwing away lots of wood pulp if you don’t use an electronic tool. If you stick with it, you’ll acquire an understanding of what really happens in your system as opposed to what is espoused by those in charge.
All models are wrong, but some are useful. – George Box
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 