Functional Specs (long and getting longer)[signed]
20 Mar 2006 - 10:09am
>> First on consequences: If ecommerce website were to fail me by $20 I >>might not be killed, but their business would suffer by more than $20.
Both E-Trade and McAfee lost me as a client/potential client in the past
week for reasons sparked by issues on their sites and I am sure the effects
were far more widespread.
Now on to the cause, the digital/web domain is the only endeavour in which
people prototype using the "real" thing. To all others a prototype is just
that, a model you construct in order to study the problem. It is impossible
to turn a model of a bridge or a plane into the "real thing", but in the
digital domain it's very easy, all you have to do is say so and the
prototype you have been working on suddenly turns into the finished product
with all the "We shall fix that in the next release" etc. that ensues.
With freedom comes responsibility, all the functional specifications in the
world will not save you if you fail to regard a prototype for what it is. I
think that's the main lesson for all of us and the message the 37signals
guys try to relate in their short paper, they are after all Ruby developers
and thus endowed with even more flexibility than the rest which at the end
requires even higher levels of responsibility.
The root of the problem lies in the building blocks of the digital/web
domain. All others architects
DCD candidate and sandwich maker extraordinaire
UB - School of Information Arts and Technologies
Free advice and opinions - refunds available. http://iat.ubalt.edu/chisik
[Please voluntarily trim replies to include only relevant quoted material.]
First on consequences: If ecommerce website were to fail me by $20 I
might not be killed, but their business would suffer by more than $20.
If Alta Vista were to consistently fail me by a more arcane option
instead of what I am looking for their business would suffer (as
indeed it did). To illustrate this further recite this sentence to a
web business owner as you deliver malfunctioning web site to him:
"It's the web. No one has ever been killed by a badly-designed web
On causes: The ease of changes to web _application_ is a myth, which
does not take into account the holistic nature of system development -
as you change something here, you need to keep in mind as well as
retest eleven things over there, because safety as well as usability
are emergent properties of system design. In my experience changes in
web application are not easy at all.
I have just finished reading "Safeware" by Nancy Leveson, it gives
nice overview of these topics. Funny too.
"And they looked upon the software, and saw that it was good. But they
just had to add this one other feature..." G.F.McCormick - Epigraph
On 3/19/06, Robert Hoekman, Jr. <mmbeta at gmail.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
> > > you would never invest the > > millions of dollars needed to build a bridge or a building without > > knowing > > exactly what was required. Web development, interaction, digital, > > rich media > > (whatever it is we do) design has to be done to the same or similar > > standard. > > I would have agreed with this statement at one time, but I've come to > realize something. It's the web. No one has ever been killed by a > badly-designed web site. Inuries are rare. > > A bridge does not have the option of failing. The web does. A web app > can be evolved, overhauled, redesigned, and refactored 1000 times in a > year. > > -r- ________________________________________________________________
Welcome to the Interaction Design Association (IxDA)!
To post to this list ....... discuss at ixda.org
List Guidelines ............ http://listguide.ixda.org/
List Help .................. http://listhelp.ixda.org/
(Un)Subscription Options ... http://subscription-options.ixda.org/
Announcements List ......... http://subscribe-announce.ixda.org/
Questions .................. lists at ixda.org
Home ....................... http://ixda.org/
Resource Library ........... http://resources.ixda.org