|
Like some of my predecessors I have to admit that it is never the same for each and every project.
"With sufficient thrust, pigs fly just fine."
Ross Callon, The Twelve Networking Truths, RFC1925
|
|
|
|
|
And I encourage that. When I write a spec, it's usually serves two purposes. First, it demonstrates what I'm trying to accomplish. Second, it shows a possible implementation of the idea. When someone else is implementing it, they almost always discover better ways of doing things, or refinements of what I've suggested. After all, when someone's in the thick of implementing something, they see possibilities and techniques that may not be obvious to someone who's just imagining it.
|
|
|
|
|
The problem with spec is that it is not done to clarify the project. (sketchflow and meeting are better at that)
The spec is done to protect both party's ass.
A spec is foremost a written contract.
That being said, "spec or not" is all about balancing the "trust versus risk" equation.
|
|
|
|
|
About documentation there are two software truth
1. Walking on water and developing software from a specification are easy if both are frozen
2. "Why do we expect documentation to accurately describe the product when the documentation is finished first?"
Rating always..... WELCOME
The only reason people get lost in thought is because it's unfamiliar territory.
|
|
|
|
|
nice quotes
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.
|
|
|
|
|
koolprasad2003 wrote: 2. "Why do we expect documentation to accurately describe the product when
the documentation is finished first?"
For me it is almost always the opposite: either the analyst finishes documentation after I have a working program or the analyst looks at how my program works to produce documentation. Either way I don't need to read the documentation (I suspect anyone does).
|
|
|
|
|
|
I sometimes do but sometimes not.
|
|
|
|
|
How can you let customers (or internal manager) approve budget without a well detailed description and development time plan ?
Without specs everyone feel unsatisfied all ends in “I believe that…”
"Verba volant, scripta manent"
|
|
|
|
|
That's a trust problem. Like any contract, specification is here to cover ass of both party.
If the provider and the customer are in the same team (being in the same company does not mean being in the same team) you do not need a specification, sketchflow is enough.
That said, I'm freelance, and I have both type of customers, the one that have complete faith and are rarely dissatisfied.
If this type of customer tell me "I believe that..." they are right, and I will do everything I can to please them, because I know they will not abuse my time, they are very precious, I would give money to keep them.
And I have customer that already abused my faith one time, and I make them pay the heavy price for the time I spend on paperwork to protect my ass with them, both in time and money and billing conditions.
Except big entities, I assume a new customer/third party is faithful until proven otherwise, so I always start with a sketchflow. (But I make them pay when I reach 1000$ worth of work)
And there is new customers that want at all price cover their ass with a contract, I accept, but the time spent on it is billed.
It is a trust problem that depends on the person that take the responsability of the risk that the other party abuse this trust.
That said, yes, for 20k $ projects, I will do some spec/paperwork even for precious customer. That's why I always want to be paid in small chunk and quickly.
|
|
|
|
|
It's why I offer (from medium project) 3 steps, all payed separately:
- Analysis, this lead to spec, time and cost plan
- developement an beta
- courses and maintenance
If customers understand that spec are a plus and can be money-saver in future (maintenance first) they pay for this service without problem
|
|
|
|
|
Where's the "Write idea down on paper and let it sit for a year before implementing it" option?
|
|
|
|
|
I generally meet with the client, then with the specialists. I am formed the general idea of the project and then I carry out it in ArgoUML.
Later on I write the code.
|
|
|
|
|
For Federal Government work, we have to follow standards that require Architecture, Conceptual Design, Detailed Design, Programming Specs and then the actual coding. Project timeframes are a year to several years.
For most business customers, we have them sign off on a design and then start coding. Usually, timeframes are measured in months.
|
|
|
|
|
I have no hard and fast rule on this one.
It depends a hell of a lot on the scope of the project, the stakeholders, and the other developers involved.
|
|
|
|
|
"We Don't Do Specs"
But, alas, I do actually try to find out what the users want to do before I do anything.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Documentation is like sex… …when it is good, it is very, very good; and when it is bad, it is better than nothing. - Dick Brandon.
While maintaining some old, outdated but still in production programs, this comes in my mind.
|
|
|
|
|
morphyna wrote: Documentation is like sex
But reading documentation is nothing like watching you know waht ... 
|
|
|
|
|
Any spec is outdated before you even put computer on. Only real coding can say what your "formal fantasy" cost. We frequently change original ideas, making 'em best.
|
|
|
|
|
...on the company and where in the company is in its lifetime.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
Honesty is the best policy, but insanity is a better defense. -- Steve Landesberg
I am not a chatbot.
|
|
|
|
|
I would be nice for a we, but there is only an I.
Why is it when you are busy everyone whats it yesterday, But when your not no-one has any work for you?
|
|
|
|
|
... that end up having nothing in common with the actual functionality we deliver 
|
|
|
|
|
As I am in research most of what we do is proof of concept. We will generate a basic framework or expectations of what we are looking at and very often the requirements will change due to available technology, parts or expense.
There has to be at least a minimum of informal specs when developing hardware, which microprocessor platform do we use? how do I communicate with the Analog to Digital converter, what’s the resolution? How often do we provide output? What algorithm do we use in signal processing and so on.
Before the device moves to product development then the specs need to be pretty well set.
It was broke, so I fixed it.
|
|
|
|
|
Usually it's rough sketch (timetable, diagrams and usually in beta period it gets a bit more formal (fancy formatting, pics, workflow, class or uml diagrams, info generated from the commentaries and few sentences to glue it together ).
But if customer is pain in the behind, then I (we) do formal specs from the start.
|
|
|
|
|
they usually change so fast when the project starts that at the end one wonders... why did we write them?
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
