Ken Ebert: Kill three birds.

(A post in my “Role Models” series…)

Killing birds is just a metaphor; who’d want to hurt something this cute? Photo credit: Valerian Gaudeau (Flickr).

Most people optimize for a single outcome.

Ken Ebert is made of smarter stuff.

When I began my career, I was like many engineers–keenly aware of issues like code quality and performance, but not so clued in to customer experience or business priorities. I’d go to team meetings, get new assignments, and head back to my cube to code away. If I was unsure how to accomplish my goals, I’d ask a senior engineer, and do my best to reflect the values they cared about. After all, they were the experts.

It gradually dawned on me that some of my engineer mentors (not many; geeks are better-rounded than popular stereotypes make them out to be…) suffered from a kind of myopia. They could build complicated and highly functional things, but they had little interest in how their constructions mapped into sales, revenue, and company success. I went through a revolution in my perspective, got religion about user experience, and spent a lot of time learning from product management.

In 2003, Symantec acquired several companies in rapid succession, and threw five sites together into a new business unit with marching orders to build a suite and conquer the world. I was tasked with architecture across the picture, and my perspective expanded again. Now it wasn’t just a single product’s success I was worrying about–I had to make or shepherd design decisions that enhanced the profitability of multiple independent products as well as the amalgam of all of them. Was it more important to make codebase X localizable, or to invest in a better install for codebase Y? If team A moved to a newer version of tomcat, would it break the integration story for our suite or impose undue burdens on team B? Resources were constrained (they always are!), time was short…

I began to sense that the way I made decisions needed to change, but it wasn’t until I worked intensely with Ken Ebert, years later, that I could put into words exactly how.

Making wise decisions about architecture, SOP on dev teams, product features, investment in R&D versus marketing–it’s like trying to solve an equation with multiple variables. Profit maximization requires that you consider more than one input at a time. This is partly what I had in mind when I blogged about the need for balance in good code, and when I blogged about optimization.

Many times I’ve heard Ken say something like this: “I think we should make feature N the centerpiece of our next release.” And my first response has been, “That’s doable, but kinda boring. Why not focus on M instead?”

When Ken nods sagely at my question, I know what’s coming.

N is glamorous, and low-risk, but it’s only useful to 3% of our customers. If we build M, we’ll address a sales inhibitor for half the funnel, plus we’ll be positioned to do features P and Q on our long-term roadmap, plus I’ll be able to get an analyst to write about it, plus …, plus …”

Ken doesn’t just kill two birds with one stone. He kills three, or five, or six.

I’m not sure how Ken manages to be so good at this, but here’s what I’ve done to try to approximate his success:

  • Evaluate in multiple time horizons.
  • Evaluate for the channel as well as direct sales.
  • Evaluate for support and professional services as well as dev.
  • Evaluate for marketing value.
  • Evaluate for opportunity cost.
  • Evaluate with an eye to domino effects.
  • Evaluate for morale and momentum.
  • Evaluate for technical debt.

Of course, nobody can do all of these, exhaustively, all the time. Don Kleinschnitz’s wisdom about putting a stake in the ground is an important counterbalance. But I find that I can think, at least briefly, about ramifications of a choice from multiple perspectives–and when I do, I often make better choices.

Thanks for the lesson, Ken.

Action Item

Look at the bulleted list of perspectives above; find one you’ve been neglecting. Pick a significant decision that’s on the horizon, and spend some time thinking seriously about that decision in the context of the neglected perspective. What did you learn?

How Software Is Like Biology

No, I’m not going to talk about genetic algorithms. (Not yet, anyway.)

DNA ~ subroutines. Photo credit: dullhunk on Flickr.

Consider the scope of concerns (roughly maps onto need for expertise) of various folks that do biological science for a living. You have organic chemists. They might not know much about why zebra mussel infestation is a problem in the Great Lakes, but they can tell you all kinds of things about why cellular respiration works or how prions replicate. You have cellular biologists, who know all about protein transcription, meiosis, and telomeres. At higher levels of abstraction/generalization, you need experts on tissues, organs, or entire organisms — and beyond them, you need folks who study speciation, ecosystems, genetic drift in populations…

Same deal with computers. At the lowest level, there are hardware folks who are all about making the chip or the bus efficient. Then there are algorithm specialists who will hone a sort or a data structure till it hums. Their expertise is critical, but not sufficient. You also need folks who are good at building well-encapsulated classes (cell membrane ~ encapsulation; nucleus ~ private methods; abstract factories = ribosomes… interesting…), folks who understand libraries (tissues/organs), folks who can see how each library and class fits into a coherent application (organism). Many analyses of software stop at the application level, but you can keep going: distributed applications clump in “herds”; herds participate in even larger and more complex (eco)systems that suffer from predation, evolution, and all the rest.

Morals to the story?

  1. Just as not all great biological scientists are experts in protein transcription, not all great computer pros are experts at low-level algorithms and data structures.
  2. Biology has a lot to teach us about building stable systems. There’s a reason organisms develop defense mechanisms, excretory capabilities, etc. Apps that evolve without analogs will die. Next time you are solving a tricky computer problem, ask yourself how biology solves the equivalent…

Example RPCD Interaction

In my last post on RPCD, I explained its key tenets. In this one, I’ll imagine one way to put it into practice.

Suppose a team is chartered to build a tool that locates birth mothers of adopted children. The team’s received some vague marching orders (“make it as easy as possible; we want to sell this as a service on facebook and the iTunes app store”). Maybe they’re using “agile” methods or even full-blown XP to guarantee that the customer’s viewpoint is represented, and that small units of work are fully processed into releasable systems on a regular basis. Or maybe they’re doing traditional waterfall, with an elaborate design phase followed by a long implementation.

Regardless, adding RPCD to this team’s behaviors might result in interactions like the following:

Step 1. Team discusses charter. They frame the charter in terms of a concrete use case. Since they don’t have a specific “real-life” customer to talk to, they postulate one. It might look like this:

Rafael just turned 18. He knows he was adopted, and he wants to find his birth mother. He knows he was born in Portland, OR on Sep 3, 1993, that his birth mother’s name was “Cindy” or “Cynthia”, and that his birth mother might have been a twin. He will interact with this product via an app on Facebook.

Step 2. Team imagines how the problem would be solved with people only, assuming that money and time is no object, and that a “white gloves” treatment is the goal. This analysis helps crystallize roles for later role play. For example:

Rafael (role = client) requests the services of a “birthmother locator” firm. The firm immediately sends an intake interviewer, Summer (role = liason) to Rafael’s home. Summer records all of Rafael’s contact info so she can interact with him in the future, clarifies Rafael’s goals, and records all information Rafael can contribute. Summer then returns to the office and arranges for Jenny (role = case mgr) to convene a group to work on Rafael’s case. The group consists of Summer and Jenny, plus Oscar (role = researcher) and Mike (role = gopher). Oscar and Mike are to begin work immediately and to report back on a daily basis. After two days, Oscar has identified 62 women whose life facts might overlap with what is known about Rafael’s birth mother. Summer contacts Rafael to report status and ask a follow-up question: does Rafael know whether his birth mother was athletic? Rafael says yes, he thinks she might have been a swimmer. Based on Rafael’s confidence in this new info, Oscar decides to narrows the search to women who appeared in high school yearbooks within +/- 5 years of 1993 and who were involved in sports. He dispatches Mike to get some HS yearbooks. He also looks in yearbooks for any girls who have a peer in the same grade, with the same last name. After three more days, Oscar has narrowed the list of candidates to two. He reports back to Summer and Jenny. Summer presents the list of candidates to Rafael and asks if he’d like them to contact the women. Rafael says no; he’ll do the final part himself. Rafael is delighted with the results and the “white gloves” treatment, and happily pays for services rendered. Summer asks him to be a reference customer, and he agrees. In fact, Rafael is so happy he can’t wait to tell all of his friends about the cool service.

Step 3. Team builds a diagram of the system, using boxes for the roles that people play. The draft a “job description” for each role.

Step 4. Team assigns roles to team members. “Fred, you’re going to pretend the client. Sally, you get to be the liason…”

Step 5. The system is deployed and goes live — in “role play” mode.

Yes, you read right. After some very early design work that can probably complete in an hour or so, the system goes into “production”. Not in its final form. Not with ultra-high standards. But in a form that allows the team to learn and refine through repeated role plays. These role plays vett the roles and the model that the team has postulated.

Role play #1 is a walk-through of exactly the scenario that the team just imagined. Fred (playing Rafael) walks to a computer, pretends to be using an app on Facebook, and says “Okay, I’m now pressing enter to submit my request.” Then Sally (playing Summer) looks at a computer screen and says, “Oh, I see that we have a new potential client. I’ll go visit him.” Already, some interesting questions should be coming to the team’s mind: Will clients be happy to be contacted by the app/service as soon as a liason like Summer is available? If so, what info should the “request help” form require so the client can be contacted? Or could a wizard automate Summer’s job? How about a chat with an online representative? Do different clients need different priorities, so that if Summer is busy when a new request arrives, she knows whether to be interrupted? Does a case manager like Jenny have to assign Summer before Summer will pay attention? The team works through these questions and continues with role play #1. Lots more questions come up as they get to the work of the researcher and the gopher. What resources will researchers have? What is the latency of getting info from those resources? How much will it cost to access those resources? Who bills the customer for expenses, and what accounting procedure must be followed? Should researchers report breakthroughs as they occur, or only once a day?

After the team works through the role play #1, it should have some intuition about which parts of the system are going to be easiest to automate. It should also have a long and ever-growing list of questions. Not all of the questions are of equal value. The team should look for ones that have major ramifications on the user experience and the scope of work, and explore those first.

Exploration takes the form of additional role plays. Since Fred was assigned the role of Rafael, his job is critical. He gets to introduce variation into the system. He shouldn’t go hog-wild all at once (“Can you bring me a pizza with your next status report?”). But he might do something like try to call his liason after a pretend hour has elapsed, to find out if any status report is available. That should cause the team some debate and head-scratching. :-) What if he asks to be notified by text in the middle of the night, no matter the hour, with new developments?

Step 6. Boundaries between automated and human components of the system are clarified. More traditional design work begins.

Step 7. The team returns to role plays whenever additional clarity is needed.

Step 8. When “the system” is delivered, it is always done as both code AND people. This means at the end of an iteration, for example, you don’t just provide a build with no bugs. You provide a role play of the system. This role play is more than a canned demo; it is an interactive demo, with people filling roles that code is not yet mature enough to handle. By viewing delivery of a “system” as delivery of a code+people ecosystem, the team is forced to consider things like how tech support will be staffed, how help will be delivered, and so forth.

Role-Play Centered Design

User-centered design (UCD) is important. I hope I’ve been a good advocate for it during my career. Its basic tenet is that software should be constructed as much as possible according to how users think and work, not according to techie considerations. (A seminal book on this topic is The Design of Everyday Things, by Donald Norman.) At its best, UCD promotes an alignment between technology and customer pain points that keeps software’s value proposition compelling. Even on a bad day, UCD makes software a lot more pleasant to use.

However, UCD rarely yields all potential benefits, which is why I’d like to suggest a specialized form of UCD for many software teams. I’ll dub this idea “Role-Play Centered Design” (RPCD, prounounced /ˈrɪpˌsɪd/) because of the way the various parts of the system come to life. (This idea is similar to–though conceived independently from–the concepts in this article from the proceedings of HCI ’07.)

Role plays can help you build software — not just entertain. Photo credit: TheArches (Flickr)


RPCD is distinguished from ordinary UCD by three key tenets.

  1. The “system” includes people.
  2. Specifics are non-negotiable.
  3. The best way to understand is to “be” the system.

Let me justify each of these ideas, and then I’ll give an example of an RPCD process at work.

The “system” includes people.

Most architectural and UML diagrams focus on software and/or hardware entities. The user’s role in the system is implicit. Even among users of activity diagrams, most workflow is computer rather than human.

This is wrong. software – people != software. Any thoughtful veteran of the industry can tell you stories about why this is so. Engineers who accept the flawed premise that only the computer side of software needs to be designed are already handicapping their UCD fatally. The system built by a software team includes people — individual users, a community, support personnel, sales folks, professional services, maintainers of docs on a web site, etc. If you let an engineer construct “the system” with no serious thought to the people, you often end up with misalignments that make it irritating to understand/use/configure/support, expensive to maintain, or even impossible to sell.

Specifics are non-negotiable.

The devil really is in the details, and if you don’t solve detailed problems, you won’t solve problems at all. The design of a system is therefore best driven by specifics–even if the specifics are only postulated. Specifics are best exemplified by use cases, and role playing forces specifics into use cases.

The best way to understand is to “be” the system.

You should “be” the software in the system, and you should “be” the people as well.

When a human being actually interviews someone in the same way an automated wizard eventually will, you learn things. The human reorders the questions or short-circuits part of the interview because she knows it’s unnecessary. Or the human gets frustrated at how needlessly cumbersome a particular part of the process is. Or the human asks some intelligent questions that you never considered. When two humans interact to model what’s eventually going to be a formal protocol, you confront asynchronicity and error handling in ways that UML or whiteboards don’t.

Modeling the system in role plays also has some other profound long-term advantages that go far beyond just what you learn. I’ll discuss these in a different post.

In my next post, I’ll give an example about how RPCD works.

Action Item

List all the people that interact with or help create your software. If your list has less than four or five unique roles, think some more. Hint: see this post.

Why Weakened Dev Teams Suffer From NIH Syndrome

(NIH = Not Invented Here)

So here’s the situation. Product Management says feature X must be built. Development scopes the feature and discovers that the “right” solution involves using code developed elsewhere. But unfortunately, the other team’s code uses different assumptions and will take some extra time to shoehorn into the new context. In other words, the right solution is too costly.

If a development team doesn’t have an architect who can advocate for the right solution based on first principles, then it uses the tried-and-true scope/schedule/resources lever (about its only negotiating tool) to push back.

The problem is that in this scenario, product management isn’t really forced to come to terms with the long term strategic consequences of doing things wrong. So the scope is adjusted, or the schedule is adjusted, or the resources are adjusted — but only enough to rescue the feature, not enough to do it right.

As a result, dev has to invent a half-baked alternative to the other team’s solution. Ad nauseum.

We look at the dev team and say that they have “Not Invented Here” Syndrome, because they never seem to use the solutions that other teams have built. In many cases, the real problem is that the Product Management and Dev don’t have an architect mediating and looking at the situation from the standpoint of maximizing the ROI of strategic technology investments.