The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Spec V's No Spec

Does anyone have any thoughts on the whole functional spec issue? I've read articles by Joel that say that not a line of code before the functional spec is done, though some companies like www.37signals.com start with the UI and say the functional specs are not functional and not to bother with them to start with.
Kieran Southern Send private email
Tuesday, January 03, 2006
 
 
Both are useful and IMHO necessary. Starting with a UI mockup is a good way to get a better UI, but it won't often help one get at all of the business rules that an app needs to implement.
comp.lang.c refugee
Tuesday, January 03, 2006
 
 
You need both.  The UI mockup to show the visual people what the product will look like and as a 30,000' overview, and a spec for the developers to follow when they build it.
Karl Perry Send private email
Tuesday, January 03, 2006
 
 
No specs if a spec means the usual billion page document that takes a year to produce before a line of code is ever written.

If specs mean a backlog of stories and a particular set that should be implemented within a two week sprint then use specs.
son of parnas
Tuesday, January 03, 2006
 
 
Prototytpe the UI, but get functional specs for the _function_.  Otherwise you could end up in 'could you make it do X when i Y' hell.  Functional specs make the user/client think about what they want & save you and them time.  Walking them through storyboarding takes some effort up front, but if you work with the same folks over time they'll think about the problem before they ask you to solve it.

In the long run, you run in fewer circles & they spend less of their budget.  Everybody wins.
a former big-fiver Send private email
Tuesday, January 03, 2006
 
 
No matter how detailed the spec is, the Client will ALWAYS change it.

I agree with some of the comments above.  I dont believe in the 6 month "Analysis" phase that produces a 150 page business process report (unless of course your working with a life critical system like Nuclear Plant management, or Space shuttle systems).

You need a basic "Functional" spec with a good starting GUI mockup to hand to the developers.  What does this do?

1) Prevents the developer from asking a 1000 questions on what to implement therefore reducing communication and interruption

2) Answers the Question,  am I done with this Function/Use case?.  If there is no spec, how would you know if you are complete.

3) When doing QA, answers the question, how is this supposed to work correctly?

4) Provides a base for Product Documentation.

Stick with a basic inital spec, and do quick interative develop cycles reviewing each cycle with the Client, updating the spec as needed.
Ben Dempsey Send private email
Tuesday, January 03, 2006
 
 
I don't think it is most efficient and productive to go without a specification.  That being said the better and more experienced your programmers are, the less you have to tell them every little detail of "normal" functionality. 

Currently, I am working without a specification.  At this point, I am an hourly contractor, so monetarily it isn't so bad.  The problem is that you end up doing things over and over and over.  Even things that you have shown the client 5x times before they still manage to completely change the requirements and functionality.  I went through this today, literally.  The client had seen the section of the program at least 5 times in detail, functioning, in meetings.  They want to change the workflow of it now.  Guess what day we were supposed to start testing with it?  That's right, today!
Joshua Volz Send private email
Wednesday, January 04, 2006
 
 
> The problem is that you end up doing things over and over and over.

If they look at it repeatedly and change their mind then how would a spec change that? The spec is just the first thing they change their mind about. It's not like a spec means anything about what you end up with.
son of parnas
Wednesday, January 04, 2006
 
 
I'm convinced that there will never be a final answer to this debate.

I do think, though, that if you're going to introduce functional specs into your workflow, the effort will be doomed unless the people writing the specs can communicate effectively.

The message from Joel is clear: if you work at Fog Creek, you're writing functional specs. Which is why He recomends learning to write well and insists on top notch writing skills in people he hires.
Paul Sharples Send private email
Wednesday, January 04, 2006
 
 
>If they look at it repeatedly and change their mind then how would a spec change that?

The spec should be viewed as the current working 'contract' for the planned delivery. It is the basis for negotiaion when things change or when expectations differ.  IMO, learned thru some not-pleasant experience, you need more than what's in peoples' heads to agree that a delivery is 'complete' for anything non-trivial.

You don't have to get all fat & hairy about it, but if they add 2 days' worth of work with a change, you can say 'I was going to deliver RevA on the 15th but these changes will cost 2 days so the RevB delivery will have to be the 17th'.  Not all clients will be happy about it but the costs & delays will be apparent, not hidden, not a surprise.
a former big-fiver Send private email
Wednesday, January 04, 2006
 
 
/negotiaion/negotiation/
a former big-fiver Send private email
Wednesday, January 04, 2006
 
 
> The spec should be viewed as the current working
> 'contract' for the planned delivery.

A real contract is at a much higher level than a functional spec.

Then we have the code and tests.

The value of another contract sitting in the middle overwhich we endlessly negotiate has proven, to put it mildly, questionable.


>  a former big-fiver

That might explain the difference in perspective :-)
son of parnas
Wednesday, January 04, 2006
 
 
Believe me, I understand the 'real' contract/'working' contract difference.  What I'm suggesting, and what has worked well for me in the past _when it can be done_, is that a decent functional spec can be a good basis for agreement between the developers and the end users on real tasks to be accomplished. 

A functional spec, to me, is not the documentary output of 7000 hours of meetings with everybody including Aunt Tillie followed by several months of wordsmithing by know-nothing straight-out-of-school-MBAs and the legal department.  That crap drove me nuts whe I was there and still does.

A functional spec, to me, _is_ 'pushing button B will cause function F to happen'.  'F' should be described in _business_ terms and not be pages of UML/use cases/etc as the aforementioned MBAs love to produce.

The worst experience I ever had was when some jacka** partner decided to have the functional spec made a term of the real contract.  NOTHING could be changed BY ANYONE, FOR ANY REASON unless there was a formal contract change order with estimates, cost centers and bills.  Gawd, that was awful!
a former big-fiver Send private email
Wednesday, January 04, 2006
 
 
Perhaps a better term for 'real tasks to be accomplished' would be 'real application function to be placed in the user's hands'.
a former big-fiver Send private email
Wednesday, January 04, 2006
 
 
We have a product, Lucid Spec, that tries to address the functional spec issue. It allows you to create a prototype and specification at the same time. It is a free beta right now and I would appreciate any and all feedback:

http://www.elegancetech.com/ls.aspx
Roger Jack Send private email
Wednesday, January 04, 2006
 
 
Option 1) Start bashing out code
Option 2) Decide on a problem to solve, then start bashing out code

It seems fairly obvious to me that if you sit down and start writing code there's no telling if you'll get a flight sim or a recipie manager, which will be of minimal use if you were wanting something to help manage your bank account.

Therefore you have to do *some* up-front thinking. If you think then write down what you thought, you have a spec. If you put a little effort into it, then other team members will be able to read and understand it.

If you take all the bright ideas you have at 2 in the morning and write them down then six months later you'll remember and be able to decide if you want to skip it or if you have to do it immediately.

Incidentally, the point of a spec is to communicate. This can be done with text, pictures, UML, maybe even mock-ups, but the point is to use what communicates most efficiently, not what is technically the most formal.


> NOTHING could be changed BY ANYONE, FOR ANY REASON unless there was a formal contract change order with estimates, cost centers and bills.  Gawd, that was awful!

Being the guy explaining why you "helpfully" lost millions of dollars in sales and wasted two years of work for a hundred person team would probably be awful, too.  (You may think it's "awful" for customers to demand that they receive the product they actually paid for, but they tend to like that sort of thing.)

You're a lot like the guy in the shop selling suits going "gawd that was awful" when talking about a job where they had to sell the customers what they wanted instead of the three-armed suits that they thought would be better.

(Ok, the paperwork necessary for filling in missing bits of the spec may have really sucked, but overall there are worse things than being able to legally hurt customers who try to go back on their word when it comes to final delivery. That'll teach the bastards to not event think about what they actually want. ;)

Sunday, January 08, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz