t-minus

Figuring out what a client really wants can be tricky business. Perhaps you see glaring problems, like voluminous corp-speak all over their site for children, and you may be tempted to focus on those. However, this client came to you to solve a particular set of problems and what’s most important to them may not be completely obvious to you. Nevertheless, it’s your job to get to the bottom of these needs, so you can be sure of sweet success. But how to do this?

The W

As with journalism, you need to narrow down the who, what, when, where, and why of a project. Who are your main contacts? What are the details of the project (the scope)? When will it start and finish? What physical or virtual space will it occupy? Why is the project being done in the first place? What problems does it solve? Asking a client to write out the answers to these questions can be a clarifying moment for everyone. Maybe the project is ridiculously simple, or more likely, quite a bit deeper than initially described. Maybe 15 people have to signoff at every stage, which could be a sign of lack of focus on the client side. It’s always better to know this stuff in advance, so just ask.

The Most Repeated

As you communicate with your client, you’ll likely notice they keep returning to certain themes. Addressing these themes directly, even if it isn’t exactly what the client envisioned when they first mentioned it, will make them feel like they are an active part of the process and show that you are really listening to them. If you are asking yourself, “Why do they always bring up X?” that’s the thing you should pay attention to.

Ignore recurring themes at your own peril, because no matter how much you sell them on your (obviously better) alternative, these issues will continue to resurface and they will have to be addressed somehow. The gaps between these recurring themes and your actual solution are often the largest source of disappointment for a client, even if your solution can bake brownies and cupcakes at the same time. As in, “Yeah, it does bake brownies and cupcakes at the same time, but all I ever wanted was crispy bacon.”

The Written Execution

Many times, changes get agreed to in ad hoc meetings and it can get confusing to track who said what, why they wanted it, and whether it was officially approved. After one of these sessions you need to send a follow up email to the client that says, “This is what we understand you are asking for, please give us the go-ahead and we will make these changes.”

This is good for two reasons. First, it gives you a verifiable paper trail to refer back to, so you know when each change was introduced, who introduced it, and why they introduced it.

Second, it gives you and the client a chance to consider these changes one final time before execution. Sometimes meetings spin off course and a certain aspect of the project gets far more attention than it deserves. In hindsight, the neon vampire logo might not make as much sense as it did in the heat of the moment. Give your client one more opportunity to vet these changes after a minute of reflection.

Take pause and appreciate with me a moment of enormous visual power, created “accidentally-by-design” in the convergence of flickr and lunch-in-a-box.

Further proof that a simple framework can yield astonishing visual results, and of course that the world wouldn’t start wobbling on its axis if we spent less time on kickin’ web graphics and more time designing our plates…

The always-sensible Jeremy Miller drew my attention to this discussion today. He highlights this point, from Ron Jeffries:

I think “requirements” always means approximately “what we think, right now, that we need”.

Limited Ink

To borrow a phrase from Nick, Gak!

This kind of talk actually changes the physical constants of the universe, significantly decreasing the inertial force of the agile development agenda adoption rate. You can just hear the seismic rumblings of indignation from space shuttle OS architects and the other remaining core demographics for the Big Design Upfront community.

If you catch it in just the right light though, on just the right time of day, you can see Ron’s point: No requirements are final. Next year, or ten years from now, we’re going to need a better boat. No doubt.

Under sub-optimal reading circumstances, on the other hand, this completely misses the point. Especially in a world of progressively more and more application infrastructure that seems to support an iterative approach. So, as we take an iterative design model more for granted every day (I was talking to someone who surprised me by referring to it as “canonical wisdom” last week), it’s worth repeating the old chestnut: Agile does not mean no design. Just because no requirements are divine, we still need to think out our applications all the way through before we start making them.

Luckily, it seems like the idea that you can just iterate your way through a series of bad designs is on its way out, but now more than ever, the web application universe could save itself some trouble by just co-opting a lesson the desktop folks had to learn the hard way. The “iterative” approach isn’t used to fix broken or bad features, it’s used to add features.

So, whether you want to list out specific database tables, class diagrams, or pseudocode for algorithms in your spec is, if not exactly immaterial, certainly is not the point. That kind of thing is best decided on a project basis, and is pretty dependent on your org chart and the size and project-load of the senior members of your team (aka. do the “architects” keep working on the project once its designed, or do they have to go off and specify something else?). There’s No Silver Bullet.

The return of the curse of the second system

Seems pretty sensible right? Well, unfortunately, sometimes work isn’t.

One of the arguments you hear someone make from time to time is that agile design eliminates the need for the “throw-away first system.” The throw-away first system is a venerable tradition of admitting our own impotence in the face of our technology and a classic strategy that begins with one of our greatest software writers and ends with the (::Williamsburg-style “how-apropos”-grimace::) waterfall development agenda. It comes from a time when the problems were hard, when Google couldn’t provide you with example code, and when a movie cost a nickel. Ladies and gentlemen, Mr. Fred Brooks:

Where a new system concept or new technology is used, one has to build a system to throw away, for even the best planning is not so omniscient as to get it right the first time. Hence plan to throw one away; you will, anyhow.

This strategy addresses a problem that was significantly more prevalent in Fred’s day: What do you do when there’s no map? And I don’t mean there’s no map for the implementation details, I mean there’s no map in the sense that you’re dealing with a totally new problem. Back in the 1960’s this was often a technology problem - less and less is this the case.

So, given that we can now instantaneously call up hundreds of free classes, code snippets, arguments for this method of optimization or the other, the famous disposable first system seems less and less necessary, to the point of being quaint, a bizarre artifact from software-prehistorical times, before the “agile revolution.” And, in the vast majority of cases, it probably isn’t necessary… Sometimes, though, you’re going to get a really high-level design problem.

Limited, Inc.

“The map is not the territory.” - Alfred Korzybski

So, here’s the amazing way in which agile methods actually end up owning a canonical piece of waterfall wisdom: Imagine, please, that you’re surrounded by people who are used to being able to solve problems with certainty and you have to acknowledge that nobody really has any idea how to design for the domain of a given problem. The only way to actually see what’s going to work here is to throw it in front of users (iterative, user-driven development, right? New-skool!) But throw what?

…the throw-away first system. Only now, the question isn’t whether the implementation is the right one, it’s whether the design was answering the right question in the first place. Which you can’t know until you try. Which is why, among other things, that even at the eight-count, you should never, ever, count Fred Brooks out.