A couple weeks ago—a lifetime, in blog time—I noted an article by 37 Signals’ Jason Fried claiming that functional specifications were no longer necessary or desirable:
Functional specifications documents lead to an illusion of agreement. A bunch of people agreeing on paragraphs of text is not real agreement. Everyone is reading the same thing, but they’re often thinking something different. This inevitably comes out in the future when it’s too late. “Wait, that’s not what I had in mind…” “Huh? That’s not how we described it.” “Yes it was and we all agreed on it — you even signed off on it.” You know the drill.
I felt uncomfortable with this pronouncement but had no hook to hang my disagreement upon because I wasn’t currently thinking about any particular software application. Now I am, and I can see from whence my discomfort arises.
Here’s what I think happened: skilled, visually-oriented web designers like the principals of 37 Signals arrived via HTML and JavaScript to Web application development and said “hey wait! You software engineers with your lengthy and political functional specs! Go away! We can do this all visually! A picture is worth a thousand-word Word document” and so on. And they’re right, to an extent. User interface mockups are very useful in specifying how software behaves; you shouldn’t do without them. But then when they confront truly dynamic and data-intensive applications, they choke. From Jeffrey Zeldman’s Web 3.0 article:
The first afflicts people who make websites. Wireframing AJAX is a bitch. The best our agency has come up with is the Chuck Jones approach: draw the key frames. Chuck Jones had an advantage: he knew what Bugs Bunny was going to do. We have to determine all the things a user might do, and wireframe the blessed moments of each possibility.
See? You can’t always specify everything visually. Sometimes verbiage is more concise than pictures.
I may be biased. I wrote at least a hundred requirements documents during my professional programming career, and I think those wordy documents made it easier to design the user interface. In some cases, mockups of the UI couldn’t possibly suffice to explain what went on behind the pretty Web pages. I still have nightmares over the accounting details of handling the VAT tax and Euro conversion in Oracle Financials. The Web-based version of Oracle Receivables was very simple and intuitive. I was particularly pleased with the search box I fought for that provided full-text search of invoices. But the capabilities exposed via Web-based Receivables or even the Oracle Forms version used by AR accountants weren’t concise and comprehensive ways to specify everything Receivables did. Much of it needed to be explained and confirmed in text. Pictures were helpful too but not enough on their own. Or if they could have been enough on their own, they would have taken far too much time to construct.
I think that the visual and the wordy need to work hand in hand to specify what good software is and what it will do. I think the demo Megite parenting page [update 2/20: page currently nonfunctional] is a first start at what a parenting news page might look like. To achieve what I envision, it needs a number of additional features that would best be described in text, not by producing a bazillion visual mockups showing different situations. Here are the things it might be nice to do:
- Provide filtering by keyword (how about hooking it up to BlogBridge smart feeds?)
- Pivot on subtopic, for example, I’d like to see everything about work and family gathered together
- Filter out sites like Haloscan
- At the same time Haloscan is filtered out, count comments to see which posts are most popular from a broader conversational perspective
- Offer tagging and voting capabilities
- Offer visual customization to the editor constructing the topic tracker
There’s more too, but I’m not prepared to make this into the comprehensive what-should-topic-trackers-do requirements spec. I’ve exhausted my blogging energy by writing about web designers vs. software engineers. In conclusion: we need both visual and verbal representations of what software will do. Don’t play a dirge for the functional requirements document yet.
10 Comments
This was sort of addressed on the 37signals blog, in this article: http://www.37signals.com/svn/archives2/the_interface_as_a_spec_including_stories_inline.php
Jason talks about putting little notes in the mocked-up interface where the functionality wouldn’t be entirely obvious. I suppose it’s sort of like a post-it note on the Chuck Jones wireframe saying “if Bugs just stands there eating the carrot, then…”
I guess that works for simpler cases, but it seems to me that for data-intensive and highly dynamic apps, text descriptions of requirements may be more concise and useful.
you pulled the carr post? surprising?
hi again. i couldn’t resist leaving a comment here also–our paths cross on this one too. i too have written a hundred specs, and work as an arbiter between clients and programmers/developers. (and i also research HCI).
you say: “I think that the visual and the wordy need to work hand in hand to specify what good software is and what it will do.” I could not agree more–i have never yet come across a UI mockup or technical spec that is sufficient, and, more-to-the-point, legible to the clients.
i constantly find that in the race to build a site/tool, to produce that end product, the complex ways in which a site is intended to be used by specific communities gets left out of the picture. and, more interestingly, sometimes it is impossible to predict how certain tools will be used, because users have not (cannot) articulate what it is they *actually* do.
your own work with the Megite site–you’re working as a programmer, developer, and a potential user. you are occupying all three positions (i think) and creating from this perspective. (do correct me if i am off base here!)
this ability to occupy the role of the user–to predict user-behaviors, and needs, and envision interactions–this is also one large facet i find missing; i find a consistent disconnect between the realms of users and developers/programmers, who speak in different languages. this can be a source of tremendous frustration, and also why, when usability testing comes along, the programmers I work with want to run and hide!
i would say (and so does research) that much *more* time needs to go into the wordiness and conversations that occur before a single key stroke of programming. either in the form of documents, interfaces, user-surveys, user-testing of similar tools, and f2f meetings.
sorry to drone on! must go back to “real” work now. i’ve enjoyed both your blogs, and will check in again.
Yes, I pulled the Carr post. After I had calmed down, it seemed overwrought even though in the context of the 100% male conversation I was entering, I think my distress was reasonable. It’s likely impossible for me to communicate what a punch in the stomach that phrase was to me given my outsider status–as not just a woman, but as a stay-at-home mom–so I decided I didn’t want to continue the conversation.
I know, blogging code says: don’t ever pull a post. Whatever. I’ve got to do this in a way that works for me or I’ll have to quit.
Joy, it is so great to find someone who can relate to both my blogs. Sometimes I feel like two completely different people: the technologist and the mother.
Yes, as far as my Momorandum experiment goes, I’m playing all roles. Megite is developed by someone else, so I can only be a user and tester on that, but I have built some pieces that may become my own version some day. I agree–there is often a huge disconnect between programmers and users. I’ve seen that in all my development jobs. And we see it now in Web 2.0, where many systems are developed with geeks in mind. Megite is one good example: it only works for heavily linked domains. Momblogs don’t link much too each other, but it doesn’t mean there aren’t conversations rippling through.
Anyway, nice to meet you! I will be keeping up with your blog for sure.
with one crucial difference–you are in Maui (if blogger profile is right) while i am in “10 below” effing Michigan!!
actually, I am right here:
http://www.matrix.msu.edu/
maybe our paths will cross one day–hopefully *not* in michigan;)
Hi again Joy,
I’ll only be in Maui for another six weeks, but that should get me through the bulk of the winter weather, thank goodness. We’re moving to Colorado in late March to live near my family.
Your research center looks so interesting. I didn’t know anyone was looking at the use of technology in the humanities, but why not? I got back into tech by a circuitous route related to technology in social science research–I started reading up on social sciences simulations while I was studying health behavior. Then I decided I really missed programming. Shortly thereafter, I started tech blogging. Don’t know how I’ll get back into paid work, but I’m excited at the possibilities.
Yes, maybe we’ll meet some day. I hope so!
simulations? well, we are beginning some work/research in that area–we are funded by the NSF to write a catalyst proposal for a Center for Social Science Learning right now. (and I am out of my depth, big time, but it’s exciting nonetheless). maybe we can chat about it some time–i’d be interested in your take on the proposal.
circuitous route. yep, english, teaching, web design, a kid, a non-tech dissertation, and now this place. how did it happen? i count myself lucky, though.
let’s chat over email some time.
I think 37s doesn’t just think that text-based functional specs are bad. They hate even the visual specs you suggest may be a design-centric alternative. The point is to code something, not to document it. I don’t, by the way, totally agree with them.