Stories about Software


People Deserve The “What”

I don’t read blogs nearly as often these days as I used to and as I wish I currently did. A lot of this is the result of generating increasing amounts of my own content in various forms, and the rest is probably that I spend most of my time these days in coaching/administrative sorts of roles, rather than with large stretches of uninterrupted desk time. Nevertheless, I do try to sneak in a few posts or articles per day, albeit sometimes behind the bleeding edge.

The other day I noticed this post from Uncle Bob, which referenced (and thus led me to watch) this video:

One Hacker Way – Erik Meijer from Reaktor on Vimeo.

Here’s a wikipedia entry on Erik Meijer, the speaker, who, among other things, is responsible for Linq. He has a suitably impressive resume that I bore in mind my absolute love of Linq and listened through the duration of the talk, which seemed mainly to have the loose thesis, “everyone sucks at everything and I hate you, yes, specifically, you.” Removing tongue from cheek, it seemed to be garden variety contrarian talk: “{Whatever} is popular, but I’m hear to tell you that everyone is wrong and {whatever} actually {sucks/is dead/ruined Christmas} and {very new, vague concept} is what you need to do instead.” You can usually schedule a follow-up talk in a couple years of the form “{Very new, vague concept} was a great idea when I had it, but you all screwed it up, so it’s time to dust off and retry {whatever}.”

Sometimes I find this sort of thing thought provoking. I try very hard to be able to justify any practice that I use beyond just “well, that’s the way the winds are blowing” or some such. My preference is to be able to defeat serious frontal assaults out of nowhere on any given thing that I may be doing (not that I prefer to spend my days doing this, but I’d like to think I could, if necessary). So, watching critiques of practices that I employ, such as TDD, puts me into a position where I consider whether there might be better ways to solve problems that I have than the ways I’m currently solving them.

This talk didn’t have that affect on me — it didn’t really have much of any effect on me, and it actually reminded me of meetings that drone on and start to try my attention span. But that makes no sense; it’s a guy using colorful language, obviously possessed of a sense of humor, and saying things that are provocative and in direct disagreement with the way I do things. I’d expect some mix of amusement, indignation, annoyance, etc — not inattentiveness. I had to think on it a bit before I realized why this was: at the end of the day, it’s someone telling me what to do without explaining how those marching orders help me solve any kind of problem.

(Paraphrased) “Agile sucks. Commit code or you’re worthless. Quit your job if they want you to practice TDD.” My response is, more or less, “that’s… dramatic… but how does this information solve any problem at all that I have?” It’s like some kind of mandatory ISO meeting where someone explains to me that everything I’ve ever done is terrible and hell, fire and brimstone await and there are all of these important compliances and audits and such. It’s all very impressive in the presentation, but abstract and hypothetical enough that it’s hard for me not to zone out after a bit (though I have a specific personality trait/defect that I struggle mightily to pay attention to information that I don’t perceive a use for at the moment).

To pull back and get a little more abstract, let’s consider modes of information exchange where one person is delegating, in some fashion, to another person. There is the “what,” which is goal-oriented, and the “how,” which is process oriented. One or both may be present in a form of delegation (if neither is present, then what you have isn’t actually any kind of delegation). Let’s consider the three cases this allows.

How, but not What

This is really the least helpful case when it comes to knowledge workers, and it’s the least effective form of delegation. It’s the category into which Erik’s talk and the hypothetical ISO meeting fall. You’ve got someone telling you what to do, but not really tell you why you should do it or what they think will be accomplished. It’s usually from a position of authority, most typically a micro-manager. Erik’s apparent likening of software developers to military and a hierarchical organization like the Catholic Church is sort of telling here, as these are the types of institutions that espouse an operational philosophy of “it’s not your job to think, grunt, just do as I tell you.” Or, “don’t worry about what or why, just concern yourself with the how.”

Erik’s authority comes from his status/accomplishments in the industry. ISO guy’s authority comes from bureaucratic rules and civil laws. General’s authority comes from the command and control structure. All of this is effective for easily-automated process or purely tactical thinking, but it’s tended to fail pretty repeatably throughout history for knowledge workers. See, for instance, development shops that believe it’s effective to bring on a couple of architects to be the brains of writing software and then hiring legions of unskilled grunts to do the mindless work of programming.

And, apart from this being pretty ineffective when it comes to delegating to knowledge workers, it’s also a bummer. Being micromanaged sucks all of the fun out of our jobs. Imagine sitting there programming and someone comes up to you and starts telling you to adopt different coding standards and change your indentations and such. When you ask, “why,” he just calls you and idiot and tells you that “what are we trying to accomplish here” is above your pay-grade, peon.


How and What

This is probably the most common scenario these days in a lot of shops for most interactions. You get a mixture of the goal and the process — the what and the how. An iconic example of this is the former-hero developer that’s been promoted to architect/team lead/dev manager and who no longer has time to work on all of the features she otherwise might have. She fights the urge to just roll up her sleeves and do it, knowing that doesn’t scale, but that doesn’t stop her from saying, “you need to get this information stored for later… and, you should do this by using the repository pattern to encapsulate this particular…” and so on.

It’s better than how without what. You’re being told the goal and you’re part of the discussion, and I consider that table stakes for effective knowledge work. But in this case, it’s like getting a math textbook with all of the answers scribbled underneath each problem. It’s helpful for getting right answers quickly (assuming they are right), but it’s not helpful for your own learning or morale.

The trouble is, this is natural for the former hero-dev and anyone in her position. She knows what the problem is and she knows a workable solution. So wouldn’t it be beneficial for her to just share that knowledge? Well, maybe, but it’s nuanced. And I’d argue that the longer term cost of this quasi-dysfunctional arrangement tends to outweigh the short term gains.

What but not How

This is the best situation for knowledge workers. It allows for the ‘ideal’ distribution of work, if you will, since it’s like two systems being a generalized service interface. Former-hero tells you what she needs and leaves it up to you how to do that. She worries about her stuff and you worry about yours. If one of you needs input from the other, you approach that on an as needed basis and the relationship is one of mutual trust. Knowledge workers thrive in this sort of environment. Knowledge work requires creativity and creativity flourishes in low pressure, non-contentious, free environments.

Interestingly, to bring things back full circle, this is an excellent working arrangement, but it would make for a poor talk/book/blog post. Telling you what but not how would mean I’d make a post like, “I think the Java language could really be improved, but I’ll leave it to you to decide how in the comments.” Effective presentations need “How and What” — “here’s a problem that you have, and here’s how I propose that it might be fixed.”

So What?

Why do I draw these distinctions? To encourage you to be mindful of the how and the what in your interactions with others. In code, good encapsulation and separation of concerns are achieved by having public method signatures define “what” and private implementations define “how.” I think this is a good model for dividing work with others. When dealing with them, encourage them to define what they want from you rather than how they want you to do it. And when delegating, try to avoid telling people how to do things, telling them what it is you want instead.

This scales much, much better than anything else. Life is simply too complex and short for you to spend your time knowing how to solve everyone’s problems better than they do. Like it or not, you’re going to have to rely on the expertise of others, so rather than micromanaging them, trust them and spend your time getting your stuff right and figuring out how to surround yourself by as many trustworthy people as possible. And, if you do find yourself in a position to be explaining the how of something — maybe you’ve been asked or are casually conversing or whatever — make sure that you supply the “what” to go along with the “how.” If you can’t put a “what” to it and make it convincing, people will be hard pressed to care about your “how.”

Newest Most Voted
Inline Feedbacks
View all comments
Geoff Mazeroff
Geoff Mazeroff
9 years ago

I think I tweeted about that video after Uncle Bob suggested to watch it. If memory serves, I couldn’t figure out what the takeaway was supposed to be. Was it just hyberbole with satire that only the gray-beards would get, or a sound warning/message from an industry expert? There has to be a balance of having an open ear to the giants on whose shoulders you stand, and exercising due diligence to evaluate things for yourself to form your own opinions. That’s the joy/sorrow of this field — so much wonderful innovation, but sometimes the onus is on you to… Read more »

Erik Dietrich
9 years ago
Reply to  Geoff Mazeroff

I didn’t really read satire from it. It seemed to me like a mix of “I want to be provocative” and “I’m annoyed by things people are doing.” But, this actually dovetailed anyway with a post that I’d been meaning to write about “what versus how.” I think actually I wind up writing a post like that once a year or so. It seems to me that a lot of needlessly contentious effort is expended in our industry with people insisting they’ve come up with the right process that everyone should follow (or not follow). There’s this whole cottage industry… Read more »

Anthony Ruffino
9 years ago

Around minute 41 of the video, the speaker pretty much espouses your idea that developers should be given the “What but not how” when developing a software product. At the same time, he is also saying that Agile is not the ideal ‘how’ for achieving such a workplace. It is a bit ironic, but not necessarily hypocritical, as he is applying the advice to workplace management and not an actual software product. I do not agree with him that Agile will lead to a definite failure in achieving such a workplace across the board, but some of his points are… Read more »

Erik Dietrich
9 years ago

Based on the follow-up exchange that I had with him on twitter, I get the sense that his main purpose was to be provocative and to jolt people out of “just follow the best practices” thinking. In other words, I get the sense now that his intent wasn’t actually to tell anyone how to operate, per se, but to try to make it okay not to take certain practices as untouchable/unimprovable. A lot of people have gotten a lot of mileage out of following agile methodologies, practicing TDD, etc. (The flip side that the speaker appears to be pointing out… Read more »