Archive
Suboataru
Because I live in the Siberacuse NY burbs and I love their four wheel drive system, I’ve owned four Subarus – including two right now (an ’11 Impreza WRX and an ’07 Outback Wagon). Thus, I was overjoyed when I spied this homemade aquatic contraption cruising the bay during my annual fishing trip with a bunch of buddies:
I wonder if the owner tows his Suboataru behind his Subaru.
Idea Approvability
The scientifically backed and indisputable graph below shows the “approvability” percentage of an idea as a function of the perceived (by the person(s) who have the power to approve the idea) distance of the idea’s implications from the status quo. For reference, traces for two example orgs are shown. How would you plot your org’s behavior on the graph?
Properties Of Interest
Roy Fielding‘s famous PhD thesis, “Architectural Styles and the Design of Network-based Software Architectures” introduces the REST (REpresentational State Transfer) architectural style for large-scale, distributed, hypermedia-based network applications.
In his thesis, Mr. Fielding defines the non-functional property set that he uses to evaluate various architectural styles against one another:
Of course, there is no universal set of “ilities” definitions that technical stakeholders use to reason about, and evaluate, software architectures. Plus, depending on the application domain one is immersed in, some “ilities” are more important than others. Nevertheless, Mr. Fielding’s set is as good as any other that I’ve seen to date.
Whenever I see someone’s personal list of “ilities“, sometimes I discover at least one that I’ve never seen before. In Mr. Fielding’s list, the “visibility” property is one such “ility“. Here’s Mr. Fielding’s definition:
Visibility… refers to the ability of a component to monitor or mediate the interaction between two other components.
In a “distributed hypermedia systems” application like the www, visibility impacts several other properties as follows:
Visibility can enable improved performance via shared caching of interactions, scalability through layered services, reliability through reflective monitoring,
and security by allowing the interactions to be inspected by mediators (e.g., network firewalls).
I wonder what my next “ility” discovery will be?
P Equals R Minus C
Being a dufus, I’m constantly trying to use the power of abstraction (a.k.a selective ignorance) to syntegrate complex issues, problems, situations, and relationships up into ridiculously simple generalizations that are, of course, wrong. For example, take the classic business performance equation below.
In the sliver of dufus-land that aligns with reality, if revenues don’t consistently exceed costs, it’s just a matter of time before a new or established business goes kaput, no?
When a company starts up, by definition, it has only a handful of people who fulfill all of the roles in the right hand side of the above figure needed to prosper and develop. Over time, “approved” micro-specialization, infectious hubris, empire-building, and a whole lotta BS accompanies the obsession to”grow the enterprise“. These sanctioned behaviors usually (but not always) lead to an unsustainable and cost heavy behemoth that brings the party to an end – all under the eyes of the self-proclaimed brilliant dudes who run the show. Bummer.
Was That Wrong?
In the video still below, Seinfeld’s George Costanza gets called out by his boss for doing something that most people would judge to be bad, really bad. Tongue-tied, George blurts out the hilariously funny line in the bubble.
Have you ever been in a similar situation? If so, did you agree with the objectivity of the boss’s evidence and his/her assessment? Did it matter?
The Only Means
Setting an example is not the main means of influencing another, it is the only means. – Albert Einstein
I stumbled upon the above Einstein quote while browsing Chetan Dhruve’s twitter page. One can set a good/bad example by:
- their day-to-day behavior,
- the quality of their work output, or
- (preferably) both of the above.
Since managers in DYSCOs and CLORGs are “above” work (shhhh – you’re not allowed to know and think that), they can only set an example by behavior. DICsters, however, can set an example using both approaches. Alas, it’s a real challenge to produce high quality work and behave as a role model when you’re continuously saddled with un-articulated goals that change on a whim, unreasonable schedules, and cleverly ego-centric managers. Nevertheless, it can still be done in spite of being immersed in a toxic environment. How do you do it?
Milliseconds Since The Epoch
On a recent project, our team needed a fast and portable C++ way to time stamp messages flowing into our system at high rates – down to the millisecond level of resolution. Here’s the boost-based implementation that I concocted. Notice the classic “midnight, January 1, 1970” epoch and the 64 bits required to preclude multiple rollovers in milliseconds since the epoch. What would your fast and portable C++ solution look like?
Update 1/5/13: Ever since C++11 arrived on the scene, Boost.Date_Time is longer needed for high resolution timing. As the “Milliseconds Since The Epoch 2” post shows, this functionality is now standard in the <chrono> library.
Telltale Signs Of A Failed Software Project
Like everyone else who’s worked on a slew of team-based software development projects, uber C++ blogger Danny Kalev has his own thoughts on why projects fail. In “Telltale Signs of a Failed Software Project, Part I“, Danny ominously describes “The Emperor’s New Clothes Syndrome” as follows:
The first ominous sign is the emperor’s new clothes syndrome — as a new recruit, you try to study the project. You’re reading the specifications, perusing those lovely Data Flow Diagrams (DFDs) or UML charts and you still can’t get the hang of it. “What on earth were they thinking? It simply doesn’t add up!” you’re muttering silently. At some point you realize that it’s not you — it’s the project itself. What you’ve been reading is simply a collection of smoke and mirror effects meant to appease the high management. Little by little you get the picture: your colleagues know that it’s not working but they won’t admit it in public. If you dare exposing the truth you’ll be denounced as an ignorant, misfit traitor. You have two choices: quit silently, or join the rest, pretending all is well.
Hmm, I think Mr. Kalev may have missed the point that his second-to-last sentence; “exposing the truth and being denounced as an ignorant, misfit traitor“, is also a choice – albeit one that is auto-discarded by all sane persons. Ya see, if you’re not perceived to be a cross-eyed Columbo, a court-jester, or an innocent (but naive) child when you state your concern, you’re sure to get hosed down by the powers that be.
Have you ever tried to call-it-like-ya-see-it in front of the papal infallibles? If so, which halloween costume did you don? Columbo, Court-Jester, Innocent Child, or “other“? Surely, you’ve done it at least once, right? If not, why not? If so, then what kinda blowback did you receive – and did it force you into “quiet desperation” mode? Come onnnnnnnnn, don’t be shy – share your story with BD00 and the two other regular readers of this blog.
G-Spot
In chapter 3 of “In The Plex“, Steven Levy describes the culture within Google. Check out these “behaviors“…
The highlight of the TGIFs is always the no-holds-barred Q and A. Using an internal program called Dory, employees rate questions submitted online, with the more popular ones rising to the top. Brin and Page respond to even seemingly hostile questions with equanimity, answering them in all seriousness with no offense taken. In a typical session, someone asked why the newly hired chief financial officer had gotten such a big contract. Sergey patiently explained that the marketplace had set salaries high for someone filling that role and Google couldn’t fill it with a quality person if it underpaid.
Even more time is saved by Google’s ubiquitous “tech stops” spread about the buildings: these are, in essence, tiny computer shops, indicated by neon markers. When a piece of equipment fails or there is a sudden need for a new mouse or phone charger, all a Googler needs to do is walk no more than a few hundred feet to one of those locations, and almost instantly he or she will be made whole.
What are some of the behaviors, or (maybe more importantly) lack thereof, that your company exhibits that characterize its culture? Fuggedaboud what is espoused. What is actually “visible and feelable” that sets your company apart from the mooo-herd?
If you were an employee who saw evidence every single day that your company valued your presence, would you not be more loyal? The Montessori kids who started Google thought about those questions and asked, Why? Why? Why? If Google ever hits really hard times, it will be telling to see whether the sushi quality falls and the power chargers disappear from the conference rooms.
Complicated != Complex
For the non-geeks reading this post, the “!=” symbol is the C++ programming language token for “not equal“.
It seems like a lot of people think that classifying something as “complex” is the same as calling it “complicated“, and vice-versa. That conclusion can be, and often is, true, but it can also be false. I associate “complicated” with “not-understandable” – except to a select few experts. I think of “complex” to be the equivalent of something like “intricately elegant” and understandable to far more people than just experts.
Let’s take an example to illuminate my viewpoint. Assume that the black box system below functions delightfully. It’s reliable, responsive, easy to learn, and does what its users want without frustrating them in the slightest.
Now, in terms of complicated and complex, consider what the system may look like under the covers:
Of course, most users don’t give a shite what goes on under the covers, but the designing org and its people better well know what does – unless they luckily don’t have any competition to deal with, and hence, have their customers in a vice grip.
You see, at some point in time, the users will want improvements to the system as their needs evolve. If the original team of builders of implementation #1 are the only people who know the (so-called) design well enough to change it without breaking any existing capabilities, then the development org is hosed if those people leave. In effect, the org is held hostage by a small cadre of people. D’oh!
In the complex-complex implementation on the far right, even if the original builders leave the development org, the (relatively) elegant and well thought out design structure facilitates easy on-boarding of replacement builders. As an added bonus, the effort needed to add features and enhancements to the product is way less costly and risky than the other jaggedly complicated implementations.
So, given the portfolio of products in your org, how would you assess them in terms of the complexity and complicated attributes? If, and it’s probably a big IF, you could publicly communicate your assessment without fear of marginalization, or worse, how many people in your org do you think would publicly agree with your assessment? Uh, how abut privately? Would the number of public “agreers” match the number of private “agreers“?
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 