|
No plan survives first contact with the enemy. - Helmuth von Moltke
Not having a spec means not having to change the spec.
No project is ever truly complete.
Specs aren't written by the people who have to implement them and know they won't work.
|
|
|
|
|
That's fine if you are billing hourly. If you're doing a fixed price bid you need all the little details hammered out ahead of time.
When a change comes along from there you write an addendum to the original spec and get paid for that too.
|
|
|
|
|
Addendums can become bigger than the original as scope has a nasty habit of changing.
Ask the low bidder on a government contract. 
|
|
|
|
|
thrakazog wrote: fixed price bid
Those are for suckers. 
I've never yet met a situation where "all the little details" could be "hammered out ahead of time"; all have required a delightfuil amount of R&D... that's where the fun is.
If you have time to hammer out all the little details, you might as well just write the darn thing.
|
|
|
|
|
PIEBALDconsult wrote: Those are for suckers.
Agreed.
However fixed price bidding is a requirement from some of our customers. Some places want to know exactly what things are going to cost them so they can work it into the budget. So if we want the work we have to play the game. There are times when we do end up with a fair amount developed before the plan is agreed to. Those are the risks of business I guess.
|
|
|
|
|
it says it all... and as long as i don't want the client to tell me a dev is not what he was expecting, i write specs first, make them approved, then code. since then, every scope change is a change request...
|
|
|
|
|
toxcct wrote: i write specs first, make them approved, then code.
I dont know your area of work, but how can the customers know what they want when they are not able to do it in the first place?
Here, we write software for the interpretaion of data generated by complicated measurements. We need an interative sceme with much R&D (on both sides) in between.
The (maybe company internal) customers requirement is "In need that data visualized.". I visualize it.
The customer says "I need another visualisation like $THAT, but different. And I need to access $THOSE data for comparison."
We dont want to write fixed specs, impement them and then notice how the customer can not possibly use our software.
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
jhwurmbach wrote: I dont know your area of work, but how can the customers know what they want when they are not able to do it in the first place?
because that's exactly what i working for.
i'm not a software "editor". My compagny produces unit software, that is, a single order for a software that is supposed to fit a business gap...
so I believe they (the client) know better than us (the developers) their business.
That's the functional specs, and there a rarely problems to have them validated.
for the Technical design, as you say, the client say "i want something like $THAT". it's where our job is important in advising the client in what the technical part will met their need.
once each part is ok with the specs, they are officially validated, and then developers can start working...
|
|
|
|
|
OK - thats probably a whole different market from the R&D-driven engeneering we do here.
So you are closely modeling the things the customer is ATM doing with "pen & paper".
Let's think the unthinkable, let's do the undoable, let's prepare to grapple with the ineffable itself, and see if we may not eff it after all.
Douglas Adams, "Dirk Gently's Holistic Detective Agency"
|
|
|
|
|
|
It also means that there is no definition of when the work is done. 
Dale Thompson
|
|
|
|
|
Which is correct.
|
|
|
|
|
Not having a spec means you do all the work yourself. Since there's no spec, nobody can help you.
Not having a spec means you get into arguments with the client about what they said and what you heard.
Not having a spec means your team forgets what they're actually trying to accomplish.
Not having a spec means your team forgets the decisions graph that lead up to the requirement and its design.
Specs are written so that other people can write unit tests and acceptance tests against the specs.
Specs are written to figure out what needs further specs.
Specs are written so that everyone involved in the business can make sure that the spec works for their particular work process.
and so forth.
Marc
|
|
|
|
|
The Before-Design specs come from the users - and as a rule, they rarely know what they're talking about.
In this respect, it's on par with forcasting the weather for one's vacation in 2012. The only thing you can be sure of is that there will be some.
"The difference between genius and stupidity is that genius has its limits." - Albert Einstein
"How do you find out if you're unwanted if everyone you try to ask tells you to go away?" - Balboos HaGadol
|
|
|
|
|
And even then, it's nearly impossible to capture all the changes, and more importantly, the reasons for those changes!
Marc
|
|
|
|
|
Reasons?? We don't need no stinkin' reasons to change the specs 
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
|
Or to change the specs back to how it was in the initial design! 
|
|
|
|
|
Chris Maunder wrote: We don't need no stinkin' reasons to change the specs
' ' just about sums it up
"I guess it's what separates the professionals from the drag and drop, girly wirly, namby pamby, wishy washy, can't code for crap types." - Pete O'Hanlon
|
|
|
|
|
Yeah, that was my vote also. In 20+ years, I've never seen a system that was coded to the original specs. Spec are what's referred to as a living document.
|
|
|
|
|
I agree with you that a spec changes over the course of the life time of the application. I also want to add that it depends on who you work for. As a contractor or consultant, I must code to spec and changes are discourage once the spec/design is signed. Its all depend on who is paying the bill. The more stricted process followed, the more successful of the project delivered on time and on budget.
|
|
|
|
|
|
I haven't found yet customers that know in advance what they expect from a product. Allways they have new ideas.
ADVICE: Avoid giving them ideas !
36. When you surround an army, leave an outlet free.
...
Do not press a desperate foe too hard.
SUN-TZU - Art of War
|
|
|
|
|
Its our job to give them ideas and help them realized in advance what to expect by writing specifications. Now they must sign the agree upon specs. Any more new ideas, treat it as additional contract.
|
|
|
|
|
I swear I saw one this morning!
|
|
|
|
|
It was moved to the correct site after everyone ran around in a panic about a *dramatic music* Java poll *gasp* appeared mistakenly on CodeProject.
cheers,
Chris Maunder
CodeProject.com : C++ MVP
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
