Archive
Working Code Over Comprehensive Documentation
Comprehensiveness is the enemy of comprehensibility – Martin Fowler
Martin’s quote may be the main reason why this preference was written into the Agile Manifesto…
Working software over comprehensive documentation
Obviously, it doesn’t say “Working software and no documentation“. I’d bet my house that Martin and his fellow colleagues who conjured up the manifesto intentionally stuck the word “comprehensive” in there for a reason. And the reason is that “good” documentation reduces costs in both the short and long runs. In addition, check out what the Grade-ster has to say:
The code tells the story, but not the whole story – Grady Booch
Now that the context for this post has been set, I’d like to put in a plug for Simon Brown’s terrific work on the subject of lightweight software architecture documentation. In tribute to Simon, I decided to hoist a few of his slides that resonate with me.
Note that the last graphic is my (and perhaps Simon’s?) way of promoting standardized UML-sketching for recording and communicating software architectures. Of course, if you don’t record and communicate your software architectures, then reading this post was a waste of your time; and I’m sorry for that.
Slap Me, Please
Damn it, I hired you to get results! (… and I don’t care what means you use, so don’t give me any details) – Unknown CEO, President, SVP, VP, Director, or Manager
Some of the people who run our institutions don’t care much about “means“. Although they’ll never publicly admit it, they only care that results are achieved by whatever “means” possible. That is, until the “means” comes back to hit them where it counts – in the wallet. Even then, after the wallet has been lightened with a slap on the wrist, it’s back to business as usual. Wall St.? Investment banks? Bad ass corpocracies?
Encroach And Dominate
Systems tend to grow, and as they grow, they encroach – John Gall (The Systems Bible)
Complex societies, once established, tend to expand and dominate – Joseph Tainter (The Collapse Of Complex Societies)
Related articles
- The Gall Of That Man! (bulldozer00.com)
- It’s Systems As Such (bulldozer00.com)
How Can We Make This Simpler?
The biggest threat to success in software development is the Escalation of Unessential Complexity (EUC). Like stress is to humans, EUC is a silent project/product killer lurking in the shadows – ready to pounce. If your team isn’t constantly asking “how can we make this simpler?” as time ticks by and money gets burned, then your project and product will probably get hosed somewhere downstream.
But wait! It’s even worse than you think. Asking “how can we make this simpler?” applies to all levels and areas of a project: requirements, architecture, design, code, tools, and process. Simply applying continuous inquiry to one or two areas might delay armageddon, but you’ll still probably get hosed.
If you dwell in a culture that reveres or is ignorant of EUC, then you most likely won’t ever hear the question “how can we make this simpler?” getting asked.
But no need to fret. All ya gotta do to calm your mind is embrace this Gallism :
In complex systems, malfunction and even total malfunction may not be detectable for long periods, if ever – John Gall
The New G-Spot
Before reading any further, please contemplate this Box cutter:
Essentially, all models are wrong, but some are useful- George Box
Now, let’s start with a pair of “model” problem-system and control-system templates:
Next, let’s hypothesize a new composite system that you designed, built, and deployed to “solve a vexing socio-technical problem“. You diligently employed the dorky BD00 templates, your brain, and your positional power to form a “semi–effective” marriage between your specific problem (indicated by the blue, scoped boundary) and your specific controller (indicated by non-white components):
Although your new system may appear to be alleviating (or least containing) the problem, looks can be (and usually are) deceiving. Before you pat yourself on the back for being a “problem solver“, please contemplate these Gall-isms:
New systems generate new problems – John Gall
Systems Develop Goals Of Their Own The Instant They Come Into Being – John Gall
Intra-system Goals Come First – John Gall
Thus, according to the Gallster, the a-priori and noble “G” you designed into your fabulous controller subsystem will eventually be usurped (sooner rather than later) by the emergent “G” of the new composite system entity. Sometimes the new “G” totally obscures the original “G” so thoroughly that, given enough time, nobody can even remember what the original “G” was. D’oh!
And what might this new system “G-Spot” be? Could it be to perpetuate and maybe even exacerbate the original problem so that the new system (especially the controller subsystem) can grow and thrive? After all, if the problem gets solved, then there will be no more need for the controller subsystem. In effect, the new system would be devouring itself as it solved the problem. But wait! That can’t happen because it would be a fruitless attempt to violate this Gall-Shirky pair:
Systems Tend To Grow, And As They Grow, They Encroach – John Gall
Institutions Tend To Preserve The Problem To Which They Are The Solution – Clay Shirky
An alternative BD00 quote rip-off is:
Systems, like people, tend not to consume themselves as food.
Can you concoct another alternative rip-off quote?
124 To 858
When a friend recently pointed me toward hupso.com, here’s what I discovered:
As you can see, the Hupso.com and the WordPress.com stats aren’t even in the same ballpark. Since I believe my wordpress stats are more accurate, the bulldozer.com “franchise” is potentially worth $431 per year; or $36 per month (LOL!).
Oh well, I guess I can’t quit my day job. But that’s OK. Despite the anti-corpo rants I hoist on this blawg, I like my day job and I like the people I work with and I like the people I work for.
In any situation one finds themself in, it could always be better or it could always be worse. But when one only thinks in terms of “it could always be better and can never be worse“, then there’s likely to be trouble on the horizon.
Stacked Ranking
The title of this post sounds like the stodgy name of some inhumane, BS, corpo process under which “supervisors” evaluate their children, I mean, induhvidual contributors. But wait! It’s the Valve way.
You don’t know who Valve is? Valve is a company that creates massive, multi-player, online games. According to “economist-in-residence“, Yanis Varoufakis, Valve rakes in $1B in revenue even though they have a measly 300 employees. Also, according to Yanis (and their employee handbook), they are totally flat chested. There’s not a single boob, oops, I mean “boss“, in the entire community. D’oh!
The employee handbook spells out the details of the “Stacked Ranking” process, but in summary, peers rate each other once a year according to these four, equally-weighted metrics:
Skill Level/Technical Ability
Productivity/Output
Group Contribution
Product Contribution
Notice that there’s no long list of patriarchical, corpo-BS ditties like these in the four simple Valve metrics:
- Takes initiative and is a self-starter
- Knows how to acquire resources when needed
- Manages time well
- Knows how to prioritize tasks
- Yada, yada, yada
As you might guess, the stack rankings are used for salary adjustment:
…stack ranking is done in order to gain insight into who’s providing the most value at the company and to thereby adjust each person’s compensation to be commensurate with his or her actual value. Valve pays people very well compared to industry norms. Our profitability per employee is higher than that of Google or Amazon or Microsoft, and we believe strongly that the right thing to do in that case is to put a maximum amount of money back into each employee’s pocket. Valve does not win if you’re paid less than the value you create. Over time, compensation gets adjusted to fit an employee’s internal peer-driven valuation. – The Valve Employee Handbook
Whenever I serendipitously discover jewels in the rough like Valve, SAS Institute, HCL Technologies, Semco, Zappos.com, etc, I always ask myself why they’re rare exceptions to the herd of standard, cookie-cutter corpricracies that dominate the business world. The best answer I can conjure up is this Ackoff-ism:
The only thing harder than starting something new is stopping something old. – Russ Ackoff
But it’s prolly something more pragmatic than that. Since corpo profits seem to keep rising, there is no burning need to change anything, let alone blow up the org and re-design it from scratch to be both socially and financially successful. That would be like asking the king to willingly give up the keys to his kingdom.
“T”, “Hyphen”, And “I” People
In this:
the company talks about “T” people:
We value “T-shaped” people. That is, people who are both generalists (highly skilled at a broad set of valuable things—the top of the T) and also experts (among the best in their field within a narrow discipline—the vertical leg of the T). We often have to pass on people who are very strong generalists without expertise, or vice versa. An expert who is too narrow has difficulty collaborating. A generalist who doesn’t go deep enough in a single area ends up on the margins, not really contributing as an individual.
That’s too bad for the typical borg. These beasts actively recruit and develop horizontal “hypen” (mgrs, execs) people and vertical “I” (induhvidual contributors) people. Of course, the stewards of these dinosaurs get what they wish for. On top of that, anybody who tries to self-improve towards a “T” person is silently ignored. It would screw up the nice and tidy employee-in-a-box process of emasculation.
Glad To Be Of Service
Much of my thinking on hierarchy and unconsciously veiled corpo-insanity is founded on the ideas of systems thinkers and cyberneticians like Ackoff, Deming, Beer, Ashby, Wiener, Forrester, Meadows, Senge, Wheatley, Warfield, Bateson, Gall, Powers, etc. But mostly, my dirty thinking is rooted in the life work of William T. Livingston and his most influential mentor, Rudy Starkermann.
Over the years, Bill has always claimed that his work on socio-technical dysfunction may not be right, but it is irrefutable because it is derived from natures laws (mostly thermodynamics and control theory). And in walking his talk, Bill constantly solicits feedback and asks for counterexamples that disprove his theories.
After I discovered and wrote about Valve Inc, I threw this skunk on my friend’s table:
Here’s Bill’s response and my response to his response:
With his approval, which I have no doubt whatsoever that I’ll receive, I’ll try to decode and post the results of Bill’s research when I get it.
Related articles
- D4P Has Been Hatched (bulldozer00.com) ( Download the D4P book for free)
- D4P And D4F (bulldozer00.com)
- D4P4D (bulldozer00.com)
- D4P4D Tweetfest (bulldozer00.com)
Come To Papa!
I recently listened to a fascinating podcast interview of Valve Inc‘s “economist-in-residence“, Yanis Varoufakis. According to Yanis, the company is still organizationally flat after 17 years of existence.
The thought early on at Valve was that the maximum limit to flatness would be around 50-60 people. Above that, in order to keep the wheels from falling off, some form of hierarchy would be required for concerted coordination. However, currently at 300+ employees, Valve has managed to blow through that artificial barrier and remain flat. Mind you, this is not a company solely made up of like-thinking engineers. There are also artists, animators, writers, and accountants running around like a herd of cats inefficiently doing the shit that brings in $1B in revenue each year.
According to Yanis, in order to maintain their egalitarian culture, Valve can’t afford to grow too quickly. That’s because they have to deprogram people who are hired in from hierarchical borgs as former bosses who expect others to work for them, and former workers who expect to be “directed” by a boss. If Valve didn’t do this, their culture would get eaten alive by the pervasive and mighty command-and-control mindset. The spontaneity, creativity, and togetherness that power their revenue machine would be lost forever.
Nevertheless, Valve is pragmatic with respect to hierarchy:
“Valve is not averse to all organizational structure—it crops up in many forms all the time, temporarily. But problems show up when hierarchy or codified divisions of labor either haven’t been created by the group’s members or when those structures persist for long periods of time. We believe those structures inevitably begin to serve their own needs rather than those of Valve’s customers. The hierarchy will begin to reinforce its own structure by hiring people who fit its shape, adding people to fill subordinate support roles. Its members are also incented to engage in rent-seeking behaviors that take advantage of the power structure rather than focusing on simply delivering value to customers.” – The Valve employee handbook
Whether Valve knows it or not, their success is due to their respect of some of Gall’s system laws:
- Systems develop goals of their own as soon as they come into existence – and intra-system goals come first.
- Loose systems last longer and work better. Efficient systems are dangerous to themselves and others.
Why am I here?
WTF?
Meh!
D'oh!
My BTC Address
Bulldozer00's Blog 