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.