The Case for Functional Business Specification Documents

FLiP is getting a little long in the tooth. When Jeff Peters and I codified Hal Helms’s development methodology theories in our Fusebox book and coined the name “Fusebox Lifecycle Process”, we were living very much in a “web 1.0″ world. Fusebox was developed as a page-centric controller framework and we all built page-centric applications. “Rich Internet Applications” had yet to be coined by Jeremy Allaire, the notion of a “Flash programmer” had just crowned, and Flex wasn’t even a twinkle in Ted Patrick’s eye.

Times have changed, but FLiP has not.

However, this isn’t a call to arms for updating the core principles of FLiP. We’ve had some outstanding successes with FLiP. Despite the name, FLiP works for non-Fusebox projects. Many of us have rearranged portions of FLiP to suit our development practices and our customer idiosyncrasies. And a number of folks have gotten a free ride from pandering to the FLiP lovers at conferences. The driving principle of FLiP (that a client doesn’t know what they want until they see it), the incontrovertible iterative system of feedback, and the specific phases of the process are all golden. What’s not golden is the tools we use to
accomplish the job.

I’ve always been a fan of monumental functional specification tomes. (More about those FLiP tools in a minute.) Functional specification documents (or “spec docs” or “business specifications” or just “specs”) are always like soft, warm, safe, places to me as a developer. Nothing can hurt me when I’ve got a big, fat spec doc in hand. It’s my bible, it’s my life preserver. And no, no amount of FLiPping can answer a question like, “What should happen to our application when the third party business accounts processor returns a -34 status code instead of the expected code of R-12.” Would you really put a detail like that into a DevNote on the bottom of a screen? Which screen? If you’re not putting that in a DevNote, where are you putting it? I don’t know about you, but I’m putting it into my spec doc. In fact, I’m putting a lot of stuff into my spec docs. As a developer, I absolutely love answering that question by saying, “Well actually in section 4.12.4.6.2, bullet item 2, it states very clearly what we should do when the processor returns anything other than R-12.” And as an application architect, I really enjoy answering that question by saying, “Quit yer bitchin’, it’s in the spec.”

Ahh, the pleasure of geeking out with a spec doc.

Our mutual friend Joel Spolsky (What??!! You don’t subscribe to Joel’s newsletter? Do it right now.) has written at length about spec docs and even offered up bogus and real-world samples to get your juices flowing. Writing specs is not a simple thing though. It won’t work to grab a template like Joel’s and fill in the details of your project. There is no ten-step wizard to spit out a spec doc. The process takes action, momentum, initiative. It requires lots and lots and lots and lots and lots of communication with the client. Hell, I’ll go so far to say that it even requires a non-comatose client. (Would that all projects were so
blessed.) And writing specs is hard, bloody work. Fred Brooks wrote:

“I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation… building software will always be hard. There is inherently no silver bullet.”

So true, so true. A recent Webapper customer spent nearly sixty thousand bucks and four man-months to produce a spec doc. That’s not an insignificant amount of money no matter how you slice it. But they, like us, know the power of a thorough spec doc. They, like us know that the coding phase now becomes orders of magnitude easier. And they, like us, understand the benefit of spending money to reduce uncertainty. So we’re all writing spec docs, correct? Even though FLiP mentions nothing about it? Good, good, now follow me over this-a-way…

Traditionally, the wireframing and prototyping phases were done using purpose-built wireframing tools (the two best ones, if I do say so myself, are pretty much dead products at this point: Fusium’s Rebar and Synthis’s Adalon) and Dreamweaver or whatever HTML editor you liked best. Those tools worked very well for the page-centric web 1.0 applications in vogue back yonder at the turn of the millennium. But how do you make a rapid prototype for a Flex application? What about bolting DevNotes onto Flex screens? And if there are no “pages”, what’s the use of a page-centric wireframe tool?

If you’re still reading this far, then you’re probably asking, “Nice talking, slim, but where’s the beef?” (Or maybe you aren’t. Whatever.) What are the kewl new tools? Alas, that’ll have to wait for part 2. Stay tuned.