|
you wrote them in order to know when and why to rethink your solution.
|
|
|
|
|
You write them so you can have justification for invoicing a change order 
|
|
|
|
|
Actually, the only reason I write them is because that are the basis for offer's calculations. If customer change them... the changes are payed on demand.
Regards.
--------
M.D.V. 
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpfull answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
If the customer doesn't care about specs I at least do some sketches and write my PBIs and SBIs.
If the customers demands it, then all the formal specifications are done.
I can say that few specs were actually done as it involves spending development time in them and the customers that initially were unquestionably asking for it end up trading it for daily or weekly catch up meetings.
On the other hand, well done specs are usually like a life insurance on projects.
When you don't trust your customer or/and he keeps blaming you for running late when he actually keeps changing the game rules, then you will want to have a well written spec to protect you neck 
|
|
|
|
|
If it is a formal, big job, then formal spec is a must, so both myself and the customer have something to work to, and test against.
If it is an proof-of-concept then a envelope back with a rough sketch is the best I can hope for.
Some are happy with "I want it like this *waves hands in mystical way*" others want the user manual written first.
So basically, I can't vote.
Particularly since BACON is not on the list.
Ideological Purity is no substitute for being able to stick your thumb down a pipe to stop the water
|
|
|
|
|
Well said! A spec can rarely contain more than the state of knowledge about the problem at the time of writing. So trying to come up with something "formal" is usually just a futile act. Laying down what is known and what is expected in a suitable form seems to me the better approach and has worked for me since some 30 years.
|
|
|
|
|
I'm with you there.
It depends on the work and how much Gin I had the night before.
Panic, Chaos, Destruction. My work here is done.
Drink. Get drunk. Fall over - P O'H
OK, I will win to day or my name isn't Ethel Crudacre! - DD Ethel Crudacre
I cannot live by bread alone. Bacon and ketchup are needed as well. - Trollslayer
Have a bit more patience with newbies. Of course some of them act dumb - they're often *students*, for heaven's sake - Terry Pratchett
|
|
|
|
|
We are a product company and we release a core product for customers. Customers can have customizations though. For small customizations it's always good to write the spec beforehand.
But if we jump to unknown waters, we first write a spec with our general idea, then build the spec AND code together. We take iterations to develop. The first iterations mostly output a prototype and a barely developed spec, but at the end both code and spec are well written.
Peace, ye fat guts!
|
|
|
|
|
Actually, it changes according to project. Tasks that are trivial are typically not spec'd out, whereas larger projects typically do require at the very least informal specs (formality depends on whether the dev is internal or done for somebody else).
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
