This is a short essay I wrote the other week for a design partner to explain how we think about specifying web applications, but I thought it was worth sharing. It's simple, but it seems to work really well for us.

How do you handle the specification, acceptance and measurement of the web apps you build?

[More]

One of the things I am trying to do right now is to come up with a better way to price projects based on the functionality required. The question is how to come up with the quickest way to provide the closest approximation to the real cost where clients have custom requirements but often don’t want to take the time to fully describe them.

[More]

Joel Spolsky just posted a nice review of "Dreaming in code". It was conceived of as a book about an amazing piece of software and ended up being a book about why smart teams don’t always ship.

The line in the review that resonated most for me?

"Whenever the spec describes the product in terms of adjectives (“it will be extremely cool”) rather than specifics (“it will have brushed-aluminum title bars and all the icons will be reflected a little bit, as if placed on a grand piano”) you know you’re in trouble."

I think I’m going to add that to my training materials for our design partners, because whenever a member of the client team comes into a project meeting and tries to “design by adjective”, I know it is probably the beginning of the end of the project.

Defn: The process of trying to design an application by describing it using adjectives ("cool", "cutting edge", "innovative", "powerful", "fluid" etc.). In my experience this is often done by clients who don’t really know what they want.

Design by Adjective is terminal to projects (whether graphics or programming) only when the client is unwilling to take the time to transform the generalized goals into specific requirements. There is nothing wrong with wanting a project to be "cool", "cutting edge" (or even "slow" and "difficult to use" - whatever floats your boat) as an initial statement of intent as long as the client is willing to work with the designer or architect to transform the initial intention into a set of measurable design goals.

A good rule of thumb is that you shouldn’t have anything in your project specification that you don’t have an agreed acceptance test for (what IS easy to use – how do you agree if an application is easy to use?!). If a client wants to include “design guidelines” to support a detailed set of functional requirements as guideposts (e.g. we’d rather make it quick to learn than easy to customize) that is fine, but make sure any contract clearly states that the guidelines are not deliverables or with a certain subset of clients you’re going to have a long, hard acceptance phase . . . “But my DOG couldn’t use it. Do you know how big a potential audience the dog market is? Seriously underserved too . . .”

Got the concept from a great review by Joel Spolsky. Thanks Joel!

The two biggest problems in software engineering are the process of efficiently and effectively developing requirements and the tooling required to create truly agile solutions that can change as quick as your clients mind. This posting suggests some ideas on how to solve them . . .

[More]

I have been spending a lot of time trying to figure out how to speed up the capturing and coding of requirements. For "with a twist" projects I am now finding that the main variable that drives the cost of creating an application isn’t the amount of functionality required, but the personality (and hence the amount of communications, discussions and hand holding) of the client. I think it is quite feasible to generate the code for 40-50 complex use cases in less time than some clients need to discuss a single simple use case, educating them sufficiently to allow them to decide how they’d like it to work. (It is actually a combination of personality, importance of project, management style and level of client experience in developing such projects) . . .

[More]

There isn't much point in being able to generate an application in minutes if it still takes you months to specify it. Intent Driven Design is the process we use to simplify the process of iteratively developing functional specifications for moderately complex web applications.

It is optimized for UI heavy applications and we’ve found it to be a simple but lightweight way to go from business objectives through use cases to detailed functional requirements in a meaningful way. Of course, it isn’t a silver bullet and is heavily influenced by everything from use cases to feature driven development, but we’re getting great results with it over at SystemsForge. Check out the article and let me know what you think!