Getting Real

How did I miss this entry by Jason Fried and the folks at 37signals? Not writing functional specs, but what are we going to do? This is a great conversation about integrating Agile development methods and user-centered design. David Heinemeier Hansson, who is the best thing to happen to the web development community, puts forth my favourite idea about scoping projects

Oliver, the solution to not knowing what something is going to cost is deciding what it WILL cost. Discuss the general vision for the project with your client. Decide on the major objectives you want to address. Then say: "We’re going to built the best system we can under the vision with X amount of dollars".

The system is done when you run out of dollars. Or possibly before that if the customer is happy half way through. Or possibly later than that if he likes the stuff he’s getting so much that he wants more.

Comments by David Heinemeier Hansson

I guess this makes it very easy to change the focus from "on-time and on-budget" to "on-functionality". It is just so simple, so clear. I am starting to wonder why I didn’t think of that.

Getting Real

  1. No Functional Spec

  2. Pick two – scope, timeframe, or budget

  3. Ignore details early on

This entry was posted on Thursday, April 14th, 2005 at 12:48 pm and is filed under Articles. You can follow any comments to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.

  • David Crow

    <p>Enterprise applications (among other things) are very different from the web applications that 37signals is talking about. <br />
    <br />
    Do I want my airplane build without spectifications, functional, safety, etc. <strong>HECK NO!</strong> Do I think that for most web applications we can improve the user experience by removing this functional spec, probably. <br />
    <br />
    When I look at the 37signals applications (<a href="http://www.singlefile.com/&quot; target="_blank">SingleFile</a>, <a href="http://www.basecamphq.com/&quot; target="_blank">Basecamp</a>, <a href="http://www.tadalist.com/&quot; target="_blank">TaDaList</a>, etc.) they are beautiful and elegant. Are the the same as building employee self-service for payroll, or online banking? No, but they do demonstrate the need to have more &quot;consumer-like&quot; experiences in our enterprise software. <br />
    <br />
    What I would be asking is what is the value of a functional specification to my project? Is there a way we can make the process lighter weight, or faster by removing pieces that don't contribute &quot;business value&quot;.<br />
    <br />
    These are a really uncomfortable ideas. I like contrarian viewpoints, specially when they are backed up with successful projects. The goal is to figure out what part of these ideas work in your context. Do I think that we'll get rid of project charters, budgets or timelines? No, but for sure we'll be scoping our smaller web applications differently in the future. </p>

  • Daniel Ponech

    <p>Okay, well…I'm just a simple prairie boy, unsophisticated in muh ways, but if the city folks at 37 Signals are under the impression their, or anyone else's, functional specifications, are:<br />
    <br />
    – just &quot;political&quot; docs, all about &quot;…getting to 'yes'&quot;<br />
    <br />
    – that lead to &quot;scope creep from the very start&quot;<br />
    <br />
    – in which &quot;there's very little cost in saying &quot;yeah, ok, let's&quot; add that &quot;to a Word document'&quot;<br />
    <br />
    then THEY'RE NOT WRITING PROPER FUNCTIONAL SPECIFICATIONS<br />
    <br />
    Holy crap, people! 9/10ths of &quot;enterprise organisations&quot; (telcoms, energy services, public services) haven't actually wrapped their heads around the progression from &quot;abstract (documentation, diagrams, charts, etc.), coding a skeleton app, and then homing in on the real by finishing it up with an interface&quot;<br />
    <br />
    Go' damn! It's been a decade and I'm routinely encountering examples of development processes in which &quot;business owners&quot;, with no direct connection with users, are deciding what should live on screens ('pop-ups' appearing at whim, standards ignoring button treatments, logic defying alignment) without thinking about the business rationale for doing so.<br />
    <br />
    37 Signals, in their admittedly well experienced and highly insightful position, can advance the notion &quot;We think that's [abstraction-&gt;concrete] backwards.&quot; in an effort to market their offerings, but, in the spirit of the redoubtable Crow's 'Get Real' category, I ask them to remind themselves the bulk of the clients most user experience folks encounter haven't grasped the 'backwards' position enough to know it's backwards.<br />
    <br />
    I have no doubt 37 Signals has a brilliant approach that turns traditional approaches on their ear and it will be the buzz around the taps at all the hip bars user experience people go (I'm still a little too rough around the edges to be invited). I'm willing to conjecture, however, the essence of the programme proposed will have as much to do with word games around the nature of requirements gathering as with actual deliverables. Sorta like Wittgenstein meets user experience self-definition/self-justification, but I could be way off. I often am.</p>

  • http://davidcrow.ca/ David Crow

    Enterprise applications (among other things) are very different from the web applications that 37signals is talking about.

    Do I want my airplane build without spectifications, functional, safety, etc. HECK NO! Do I think that for most web applications we can improve the user experience by removing this functional spec, probably.

    When I look at the 37signals applications (SingleFile, Basecamp, TaDaList, etc.) they are beautiful and elegant. Are the the same as building employee self-service for payroll, or online banking? No, but they do demonstrate the need to have more "consumer-like" experiences in our enterprise software.

    What I would be asking is what is the value of a functional specification to my project? Is there a way we can make the process lighter weight, or faster by removing pieces that don’t contribute "business value".

    These are a really uncomfortable ideas. I like contrarian viewpoints, specially when they are backed up with successful projects. The goal is to figure out what part of these ideas work in your context. Do I think that we’ll get rid of project charters, budgets or timelines? No, but for sure we’ll be scoping our smaller web applications differently in the future.

  • http://radiorocket.ca/ Daniel Ponech

    Okay, well…I’m just a simple prairie boy, unsophisticated in muh ways, but if the city folks at 37 Signals are under the impression their, or anyone else’s, functional specifications, are:

    – just "political" docs, all about "…getting to ‘yes’"

    – that lead to "scope creep from the very start"

    – in which "there’s very little cost in saying "yeah, ok, let’s" add that "to a Word document’"

    then THEY’RE NOT WRITING PROPER FUNCTIONAL SPECIFICATIONS

    Holy crap, people! 9/10ths of "enterprise organisations" (telcoms, energy services, public services) haven’t actually wrapped their heads around the progression from "abstract (documentation, diagrams, charts, etc.), coding a skeleton app, and then homing in on the real by finishing it up with an interface"

    Go’ damn! It’s been a decade and I’m routinely encountering examples of development processes in which "business owners", with no direct connection with users, are deciding what should live on screens (‘pop-ups’ appearing at whim, standards ignoring button treatments, logic defying alignment) without thinking about the business rationale for doing so.

    37 Signals, in their admittedly well experienced and highly insightful position, can advance the notion "We think that’s [abstraction->concrete] backwards." in an effort to market their offerings, but, in the spirit of the redoubtable Crow’s ‘Get Real’ category, I ask them to remind themselves the bulk of the clients most user experience folks encounter haven’t grasped the ‘backwards’ position enough to know it’s backwards.

    I have no doubt 37 Signals has a brilliant approach that turns traditional approaches on their ear and it will be the buzz around the taps at all the hip bars user experience people go (I’m still a little too rough around the edges to be invited). I’m willing to conjecture, however, the essence of the programme proposed will have as much to do with word games around the nature of requirements gathering as with actual deliverables. Sorta like Wittgenstein meets user experience self-definition/self-justification, but I could be way off. I often am.

  • Daniel Ponech

    <p>&quot;Enterprise applications (among other things) are very different from the web applications that 37signals is talking about.&quot; I accept that position. When you're innovating the nature of Web apps, you get to work without a net (no pun intended). With enterprise support, well, not so much. I'm down with it. Word.<br />
    <br />
    I just want to be sure the fact that because what 37Signals is proposing will work for 20 percent of solutions, doesn't mean it should end up getting carried over to the 80 percent of which most Web development consists. It's shitty (can I say &quot;shitty&quot; on the Internet?!?), I know, and I don't want to be the 'heavy' that 'harshes' a process related groove (still, you've been to the clubs with me, dude, you know I can't resist), but I think it's worth contextualising where the innovation rests and what limitations exist.<br />
    <br />
    Then again, I'm not a sophisicated easterner with Austin (<a href="http://www.airbagindustries.com/archives/007388.php&quot; target="_blank"><a href="http://www.airbagindustries.com/archives…</a>) " target="_blank"><a href="http://www.airbagindustries.com/archives/007388.p…</a>)" target="_blank">http://www.airbagindustries.com/archives/007388.p…</a>)</a> </a> experience.</p>

  • http://www.radiorocket.ca Daniel Ponech

    “Enterprise applications (among other things) are very different from the web applications that 37signals is talking about.” I accept that position. When you’re innovating the nature of Web apps, you get to work without a net (no pun intended). With enterprise support, well, not so much. I’m down with it. Word.

    I just want to be sure the fact that because what 37Signals is proposing will work for 20 percent of solutions, doesn’t mean it should end up getting carried over to the 80 percent of which most Web development consists. It’s shitty (can I say “shitty” on the Internet?!?), I know, and I don’t want to be the ‘heavy’ that ‘harshes’ a process related groove (still, you’ve been to the clubs with me, dude, you know I can’t resist), but I think it’s worth contextualising where the innovation rests and what limitations exist.

    Then again, I’m not a sophisicated easterner with Austin (http://www.airbagindustries.com/archives/007388.php) experience.