Recent posts

  • Relative readability Why go so big on type? There’s a short answer and a long answer.
  • Excuses, excuses Some people might suggest it’s not worth redesigning a site I only post to twice a year. They’re missing the point.
  • The Optimizer Every designer is wired differently. Some people are idea people, some people are artists. I’m an optimizer.
  • Indistinguishable from magic I love video games. I’m terrible at most of them. But I’m a sucker for a game with a good story.
  • Airport express Recently I learned two things about interaction design and user experience from waiting in lines at the airport.
  • Shouts and echoes There have been some situations lately that have got me thinking a lot about the Internet as a megaphone for personal communication.

Archives

30 March 2006

The undiscovered web

The folks at 37signals don't like functional specs. I don't always agree. One thing we both seem to like is analogies.

The folks at 37signals don’t like functional specs. Personally, I’d hate to work with one myself, but I think they’re necessary in larger teams. One thing we both seem to like is analogies. I’m a sucker for a good analogy. And one good turn deserves another.

This week, Ryan Singer (the Teller to Jason Fried’s Penn) took it home with this gem: “A functional spec is a map to a place you have never been. It’s like drawing a map and commiting to a route of a place you have not even set foot on.”

I think that illuminates perfectly the reason functional specs are considered necessary in large companies and considered a burden in small teams. If you’re leading 50 people into an undiscovered country, and you have to convince the entire court of Spain and Portugal to fund your expedition, then you’re going to hire a bunch of guys with sextants to plot out your journey and guess where all the gold is. If you’re 5 guys in a boat, you’re just going to set sail and head west until you find land.

I think functional specs are a symptom of a fundamental inefficiency of large corporations. The more people you have, the more time you need to spend dealing with the politics of large groups of people. This isn’t good or bad on it’s own. It’s just reality. On the flipside, there are plenty of things you can do with large groups that you can’t with small ones. Like invade a country.

Ryan and Jason are right that functional specs primarily serve a political, not a practical function. And from a purely practical perspective, they’re an absolute waste of time. And in small teams, you can’t afford to waste any time.

But in large groups, politics are a necessary evil. If you ignore them, you’ll have problems. So maybe functional specs are necessary after all. Or maybe everybody should just have smaller teams.

Comments

  1. 30 March 2006

    JamesAsher

    Well said. Maybe it’s me, but I don’t see how someone could legitimately argue soley for or against functional specs. Just seems common sense to me that in some cases they’re needed.

  2. 30 March 2006

    keith

    I think I understand the “strategy” behind these kinds of all-or-nothing, hardline statements, but they tend to focus on a pretty narrow set of controlled circumstances.

    My first reaction to this was, “well, that’s great, now if I could only get my clients to buy into it that easily.” Same thing goes with the whole “abandon meetings” things. I HATE meetings, but I realize that they are very useful for some people.

    In a large working enviornment you’ve got to be flexible and be able to adapt to other’s work style. There is no absolute right answer or right way to do anything, and when you’re talking about working with others, well, you just have to compromise at times.

    Oh, and by the way “On the flipside, there are plenty of things you can do with large groups that you can’t with small ones. Like invade a country.”

    Love that.

  3. 30 March 2006

    Wilson Miner

    Keith, I think you hit on the reason why so many people get so cheesed off at 37signals. It’s a combination of “who do these guys think they are” and “damn, i wish i could get do that” that just whips people into a frenzy.

  4. 30 March 2006

    Bobby Kellogg

    Wilson, I think you’re a good man for addressing these issues and creating a discussion. A big factor in the success and failure of a (fill-in-the-blank) team is figuring out what process works for them and how to efficiently execute it.

    One thing I take into consideration when the guys at 37Signals offer advice is how long they’ve been in the game and what types of projects they’ve worked on. If this was their first attempt - as a team straight out of school or new to the industry - I would probably take some offense to their tone and question their self-proclaimed “authority” on the issues they bring up.

    But the fact is, they have been around for a long time (in web years) and have covered a very diverse amount of territory - all which creates something you can’t learn from a book or by doing research - experience.

    In my opinion, they’ve EARNED the right to offer advice and opinions as “experts” on relevant topics like interface design, application development, business management and issues… They’ve created a successful company and managed to shift from operating on a client-directed basis to calling their own shots.

    I think what’s being drowned out in the personal attacks is the VALUE of their message. Whether you agree with it or hate the tone - it’s still valuable information.

  5. 31 March 2006

    Wilson Miner

    Bobby, I absolutely agree. There’s absolutely a lot of value in what 37signals have to say and in what they’ve done. I may not always agree, and I might cringe sometimes at the tone, but they’ve definitely earned their voice and their audience, and my respect. I think the personal attacks and potshots they’ve been garnering lately are completely uncalled for.

  6. 3 May 2006

    Laurent Szyster

    “But in large groups, politics are a necessary evil. If you ignore them, you’ll have problems. So maybe functional specs are necessary after all. Or maybe everybody should just have smaller teams.”

    Or maybe functional specs should be practically usefull.

    Like a web of static XML documents describing an API. Isn’t what REST is finally all about? Sketch up a few XML documents that specify the application programming interface, then dress them up with CSS and XSLT to produce a demo user interface.

    That’s a simple methodology for practical specifications, it works with any plateform or development stack and it produces something that large group like and that small teams can apply.

    My own 2c tip …

    Regards,

  7. 30 November 2006

    Rick Burnes

    Specs are one way to deal w/ politics in a large organization, data is another. Perhaps it’s the satellite imagery for the place you’ve never been?

    Marissa Mayer has some great comments on the use of data to minimize politics at Google here.