Essential Interface Complexity

After reading a very interesting and insightful post on the Subtraction Blog I got to thinking about what it means for an interface to be "as simple as possible".

The kernel of the post is that for most software if you are going to offend/annoy anyone, you want it to be the experts. This is because for most software the experience level of users is distributed along a bell curve. And that mean that the vast preponderance of users live smack dab in the middle (or at least in the suburbs of the middle).

Now, while true for some software, I think it is far from true for all software.

It is obviously true for the majority of consumer software (and products in general). I want my tools/products to do one thing and to do it clearly and well. Less really is more in this kind of simple "I want my music to play" or "I want that text to be red" kind of tool.

However, there is another kind of tool. That's a tool for dealing with very complex problems. There is an entire class of problems sometimes called "wicked" problems (ref. http://en.wikipedia.org/wiki/Wicked_problems) that don't really have a simple solution. In this case it may be best to think of the problem (and the UI) as having no beginner/intermediate users.

There are numerous tools that take this approach when the problem is hard (or there is a negligible number of non-expert users).

• Mathematica
• Call Center Tools
• Development Tools
• etc

It is perfectly fine to want an interface as simple as possible. But it still needs to be complex enough to capture the essential complexity of the problem you're trying to solve. And the problem(s) that these tools are trying to solve are either extremely complex or the novices get "learned up" real fast.


The Eclipse IDE is a good example of a product geared directly to an expert end user. There is little done to hide the complexity of the tool from the user. In fact, the tool allows an enormous amount of complexity (compare it to an iPod) in order to perform all of the tasks that are essential to the product.

But in a sense it is also about as simple as you could possibly make it without losing the essence of the problem that they are trying to solve with the IDE. On the other side of this is booking some travel on a site like Expedia. Here the actual moving parts behind making a booking are incredibly complex (I used to work for them and let me tell you, airlines and hotels do not make it easy on them). But what the user wants to do has little essential complexity.

"I want to go to Hawaii for 5 days next month and stay at the Hyatt on Maui" is pretty friggen simple.

That's why a "give me my crap and here's some money wizard works so well for sites like Expedia and Amazon. The user really wants something conceptually simple. It is also why a "write Office 2011" wizard would not work so well.

Easy? Yes.

Simple? Yes.

But it lacks something essential.

Organizational Breathing

So, I find myself sitting in my office watching the sun set over Seattle and thinking about organizations and how they change over time. It's interesting because I've now been around the proverbial block enough that I can start to see some patterns emerging.

Orgs need to go through a consolidate/diversify cycle to open up gaps that allow the high performing individuals to move up in the organization.

Static organizations tend towards hierarchical, seniority based promotion. This drives out some of your best performers.

It is natural from time to time to need to centralize or decentralize the functions in an organization. There are certain things that are easier to do when you have centralized a function (e.g. standardize process, share best practices, exchange tribal knowledge) and other things that are easier to do when you have decentralized a function (e.g. experiment with new methods, adopt new processes, eliminate old processes). Each of these is valuable in its own time. There's never a "perfect" organization just as there's never a perfect organism. Both organizations and organisms need to change, adapt, grow. At best they are dynamic, living things that need the freedom to change, but also the evolutionary pressure to cull the weak from the herd. That's where organizational breathing comes in.

I thought about this for quite a while when I worked at Expedia. I would often have people in my organization ask me what we were doing with the overall structure of the software development team and what would be next. They wanted to know if we would be reducing the number of independent project teams (centralizing functions like testing for example) or if we would be allowing specific business functions to "spin-off internally" (like making our corporate travel team a separate organization). Which one is right? Where are we going? Didn't we just finish centralizing (or decentralizing) that function? Can't management make up their damn minds?

Didn't you just finish inhaling (or exhaling)? Can't you make up your damn mind and just stick with one?

If we make the organization completely static then let's see what happens.

At first everything seems sane. Just business as usual. Good people get promoted. Bad people get fired (ideally). But occasionally someone makes a mistake. And then the proverbial wild rumpus starts.

Because now you have a manager or a director (or worse yet a VP) that's in over their head. They aren't doing a good job and it is affecting everyone below them. Additionally as that person's manager it may be hard to admit or see that they are in trouble. Heck, they may in fact be very gifted at "managing up" and effectively protected by that skill.

Now because the organization is static, there's no real way to move them "laterally" into a less sensitive position unless you just happen to have one open. In fact you've likely got no other option than to give them the boot because they just are not a good fit for the current position. And this is important, even if they are an otherwise excellent asset for the company overall.

"You have failed me for the final time director. Hssss. Whooosh. Hssss. Whooosh..."

That hissing and whooshing may be the breathing of an upper management despot, or it may be the talent escaping from your company.

And what of the otherwise excellent people who get stuck under great managers?

"Now wait a minute." you say. "What's so bad about being under an excellent manager?"

"Nothing at all." I say. "Provided you don't want to move up in the organization."

Ideally excellent managers tend to bring up excellent employees. So you get a bunch of excellent people reporting to your excellent manager. But in a static organization the excellent people below excellent managers end up fighting among themselves for the one spot (since we're certainly not going to reshuffle the whole org once a year or so) that your excellent manager is occupying. And then in the end you get a bunch of excellent folks leaving because of "politics" when it was really just that the game was rigged for exactly this outcome from the start.

Your excellent manager may end up leaving too since she may get sick of being undermined by the otherwise excellent people she's been training.

Sigh...

So breathe damn it!

Move people around.

Breathe in. Centralize functions (like DBAs or Testing or Program Management) when you want to spread best practices and when you want to do just a couple of LARGE projects. Or when those functions are just getting started in your company (like formal project management).

Breathe out. Scatter people into little pods of developers, testers, PMs, project managers, etc when you want to focus on a specific area of your product (like hotel search results, or better UI for selling cruises).

And each time you do it, just like breathing, go "out with the bad and in with the good." You'll be okay as long as you don't stop doing it.

Reorganization Addiction

Is your organization addicted to reorganization?

Do you re-org about once a year?

Do you do it with the intention that it will solve all kinds of problems?

Do you find yourself thinking of the next re-org as inevitable?

So do I.

Hi. My name is Bruce and I’m a re-org addict.

Re-orgs suck.

• Reorganizing is disruptive to work in progress
• Reorganizing lowers employee morale
• Reorganizing lowers productivity
• Reorganizing incurs a bunch of direct costs (e.g. office moves)
• Reorganizing always seems like a good idea at the time

I think that most reorganization can be avoided with diligent long-term planning and discipline.

Having been through several major re-orgs, I have noticed that it is true, “The seeds of the next re-org are planted in the current one.” There is an attitude that extends all the way into upper management that if you “just wait a year, another re-org will happen”. As if re-orgs were a fact of life; like the weather. I think that this is primarily the result of a lack of forward planning and looking beyond the next 6-12 months to see how each of the organization decisions made today (often for expedient, short-term reasons) play out in the long run. Of course it is hard to do that when you know that the next re-org is only a year away… and around we go.

I think that the majority of re-orgs are the direct result of the failure of leadership to make long-term plans and stick to them. By failing to do this planning, by failing to look beyond the immediate problems and short-term solutions to those problems, they lay the foundation of the next crisis. They get locked in an endless cycle of organizational firefighting. You can tell that these re-orgs don’t really solve any fundamental underlying problems since you just have another one falling on the heels of the first (or the fifteenth depending on how long you’ve been at the company).

In principle I think you can avoid this.

I think that the way out of this is the same way the founding fathers got America out of the revolution game. You need to make small predictable revolutions a way of life. Bake them into your planning. Just don’t try to do the whole thing at one big shot. The founding fathers chose every four years (two if you’re a member of the House of Representatives, six if you're a senator) as the time scale for mini-revolutions. You can do something similar.

Maybe you need to set the leaders of your current teams down in a room and ask them, “What do we want our organization to look like and act like in 2-3 years time?” Once you can get them past the “it doesn’t matter what I think since they’ll only reorganize us” phase you can start doing some real mid-term strategic planning for your organization. Write the plan down! At the same time that you generate the plan, schedule a 3-6 month checkpoint and (here’s the hard part) hold yourself to it. Then at the checkpoint, review the plan. Make any tweaks you need to and schedule another 3-6 month checkpoint.

This is really a question of discipline. Organizations need to change and grow as the business changes and the staff changes. But they tend to handle it in the way that earthquake faults handle the movement of the tectonic plates, they store up the stress until there’s a seismic event and all hell breaks loose. But by making small, predictable adjustments as there is change I think you can avoid this kind of grief.

Yes, I have a re-org problem. But at least I admit it.

One thing right about agile development

So, normally I'm fully in the camp of planning out your work and then reviewing the plans for flaws, iterating on the plans until satisfied, and only then starting to cut the final code. But just this week I ran into an interesting situation.

The situation was this, we needed a way to get rough schedules for when multiple projects would be delivered and good estimate of month-by-month capacity to take on new work for a development organization of about 400 people. No problem, right? Just go out and buy one of the inumerable tools that vendors are more than willing to sell you, right?

Yeah, right. But we needed it by next week.

So I suggested we build a CAT (Cheap Ass Tool).

Would we ever ship this tool (like to customers)? No.

Would we be keeping this tool around and iterating on it until it is perfect? No.

Did we need to cover every use case and edge condition? Oh, hell no.

And that's how I found myself doing XP (well, really just pair programming kind of... read on).

Now, I didn't realize that it was XP at first. I mean, I was just sitting in my office with the project manager responsible for handing the final reports to the VPs and a director who would have to use the tool. They sat there and said things like, "We need to capture the project's priority." And I would nod and add priority to the database and add the "right thing" to the UI so you could edit it and report on it, etc.

We never bit off more than we could do right there and then. If something big like that came up, the project manager added it to a "parking lot" list that we'd address later. I should say up front that we spent a couple of days before this meeting to compare the spreadsheets that directors were using to do their own scheduling independently. So we had agreement in principle on what we were building.

Anyway, I'd add something and the director (looking over my shoulder) would say things like, "Didn't you want that to be an integer?" Or, "I think you're off by one in that loop." And that's the way we muddled along building a tool that about 20 or so people would end up using.

I find myself in situations like this one fairly often. I wouldn't want to build an OS this way. But for a "Cheap Ass Tool" it is really fast and effective. I suspect that it could have been made even more fast and effective if I knew a bit more about the formalism of XP.

A quick aside about the formalism of XP. I find it really ironic that agile methods (and XP in particular) tend to be really light on documentation, yet there are probably more books written on how to do it right than any other method. Yup. "Stay light, don't get bogged down with formalism and process. And here's a couple of books that will give you the formula to follow."

I mean, when exactly did you last see a book on the waterfall method? Try it. Go to Amazon and search books for "software extreme" and "software waterfall".

Anyway, back to my point...

To efficiently build any good CAT the end user and the person writing the tool must be partnered. They must be in the same room. That's because (obviously) there's no other way for the requirements of the user to get to the developer.

Hmm... maybe there really is a nice place for XP. I imagine that thousands of developers can't all be wrong (insert snide comment about any obsolete language or method here). I think that like Joel Spolsky points out, you've just got to realize upfront what kind of project you're working on.

I guess that for me, agile methods are alright for this kind of project.

My Principles

I've had a couple of requests for a listing of principles that I try to keep in mind whenever I'm dealing with software development. Now understand, I don't write code for a living (although I do write code). I manage people who write code for a living. So your list of principles might be quite different depending on what role you play.

I have been adding to this list since 1998 when I started it. Actually, principle #1 has been with me for many years before that.

Bruce's Principles of Software Development

0. Until software is delivered, act as if it will always be vaporware. (This applies to hiring new employees, hiring new executives, and re-orgs as well as the release of software.)
1. When referring to computer systems, the phrase “We’ll never need more _____ than _____” is always wrong. It is wrong no matter what goes in the blanks.
2. Always design your containers to contain containers. For example, if you are building a feature to group users, make sure that groups can contain other groups as well as users. This is true unless you know that you’ll never need more layers of nesting than one (see principle #1).
3. The projected delivery date for a project is the one date on which it is guaranteed that the project will not be delivered. (Lubetkin’s Law)
4. Delete things while you know why you don’t need them. (O’Neil’s Rule)
5. It should “just work”. (Fajen’s Dictum)
6. There should only be a SINGLE source of truth. (The DRY principle)
   

While what your principles are is important (they guide your decision making), it is really important that you share your principles with those you work with. You can read my post about shared principles in software development here.


"Those are my principles. If you don't like them I have others."
- Groucho Marx