specs and screens
Jason Fried at 37 Signals recently wrote about their development methodology for building web applications which starts with the UI design and works its way out, toward the rest of the programming and development. They call their process "Getting Real" and here's the blurb that kicks off his post.
He then goes on to say "don't write a functional spec" -- a bold and fairly controversial statement in the land of software development methodology.
Having been through the "specs are hard to write" and "requirements are tough to gather" and "sometimes specs don't gather every detail about an application" and "but when I read the spec, I didn't think the feature would behave like this..." process, I know where this is coming from. But I think Jason throws the baby out with the bathwater on this post.
Functional requirements and the spec that you write that translates them from need to feature, are important. The articulation of those needs in a visual form (the UI design) is also important and most often the easiest to look at (try reading a 100 page functional spec sometime and see how you feel at the end... now try writing one), but just because it's hard to do or difficult to read, doesn't mean a spec isn't a great source of value. Especially in the domain of requirements or rules that do not manifest themselves in a visual manner. We build a ton of heavy-duty business applications with some pretty serious business rules behind them. We couldn't do that without a description of how that works. Screens are simply not enough.
Perhaps BaseCamp didn't suffer from the "time/cost/features" so typical in most of our consulting engagements. But a written record of what the application should do (not how the application should portray what it needs to do - see visual design mockups, wireframes, prototypes, etc.) is essential. It defines the scope. Without it, you're quite screwed. Having all screens and no spec is as bad as having all spec and no screens.
I think our process at OpenRoad has avoided the pitfalls of this. We do both. We have great screen design from our UX experts and we also have the ability to write great detailed specs on what the application needs to do. We design and develop specs and screens simultaneously, adding detail to both when required. We even take it up a notch and build rapid prototypes to further elicit requirements and engage our users and clients in discussions about the what and how of the application.
As found buried in the comments on the 37 Signals post, Joel on Software writes some always entertaining stuff on specs and for the ticket to writing a good spec, head over to ProcessImpact for Karl Wiegers take on the requirements gathering process. His book, Software Requirements, is great.
Getting Real is all about starting from the user interface and customer experience and then building out. Visual design first, programming second. The more traditional process is starting from the abstract (documentation, diagrams, charts, etc.), coding a skeleton app, and then homing in on the real by finishing it up with an interface. We think that's backwards.
He then goes on to say "don't write a functional spec" -- a bold and fairly controversial statement in the land of software development methodology.
Having been through the "specs are hard to write" and "requirements are tough to gather" and "sometimes specs don't gather every detail about an application" and "but when I read the spec, I didn't think the feature would behave like this..." process, I know where this is coming from. But I think Jason throws the baby out with the bathwater on this post.
Functional requirements and the spec that you write that translates them from need to feature, are important. The articulation of those needs in a visual form (the UI design) is also important and most often the easiest to look at (try reading a 100 page functional spec sometime and see how you feel at the end... now try writing one), but just because it's hard to do or difficult to read, doesn't mean a spec isn't a great source of value. Especially in the domain of requirements or rules that do not manifest themselves in a visual manner. We build a ton of heavy-duty business applications with some pretty serious business rules behind them. We couldn't do that without a description of how that works. Screens are simply not enough.
Perhaps BaseCamp didn't suffer from the "time/cost/features" so typical in most of our consulting engagements. But a written record of what the application should do (not how the application should portray what it needs to do - see visual design mockups, wireframes, prototypes, etc.) is essential. It defines the scope. Without it, you're quite screwed. Having all screens and no spec is as bad as having all spec and no screens.
I think our process at OpenRoad has avoided the pitfalls of this. We do both. We have great screen design from our UX experts and we also have the ability to write great detailed specs on what the application needs to do. We design and develop specs and screens simultaneously, adding detail to both when required. We even take it up a notch and build rapid prototypes to further elicit requirements and engage our users and clients in discussions about the what and how of the application.
As found buried in the comments on the 37 Signals post, Joel on Software writes some always entertaining stuff on specs and for the ticket to writing a good spec, head over to ProcessImpact for Karl Wiegers take on the requirements gathering process. His book, Software Requirements, is great.
0 Comments:
Post a Comment
<< Home