I've pretty much never worked from a spec. Almost all assignments came from uber-vague descriptions. So...
How often are you handed a spec before writing code? How often are the specs "good"? (not just vague buzzwords from business development)
Cheers!
Never. I don't work that way. The customer and I work together to design the system and features to be implemented. I usually work from high-level stories of how the customer expects to interact with the system.
I never have. Generally if you want a spec you need to write it yourself. But doing so, helps to solidify in your understanding of the problem and communicate said understanding to your customer/boss.
Particularly when the deliverable is to an external customer, we insist on a spec before writing code. This enables us to:
If my team isn't given a spec, we create one ourselves.
Never. Customers generally do not know how to write specs. You have to write the specs with the customer. As the developer it is up to you to insist that no code is written before specs are finalized.
I am not suggesting that you code without specs.
Never. I'm told informally what the requirements are, I write a formal requirements document, then turn it in for approval. It usually takes a few rounds of clarification to get final approval.
Always (ok, not 100% of the time but at least 95% of it). By having a business analysis work with the client to find exactly what they require and then having the client sign off it means that when you deliever what was written down they can't come back later and say that you did it wrong.
A customer should never write a spec, they should write business requirements and then BA's are responsible for making them into something that's usable.
Once the BA has completed their work it is then handed over to a solution architect which then outlines a technical implementation of the functional requirements.
If you're developing for a client (and they are paying for it) you need to make sure they sign something so they agree to what you're going to build, otherwise it can come back and bit you in the arse badly!
Some specs we get are good, others are little more than scribbles on a napkin. We always take our specs, no matter how good or bad and decompose them into a form that we can write software to. This decomposition is almost always in the form of use cases that describe the desired behavior (based on the specs or the napkin). Only after we have gone through these steps are we able to accurately plan our work, implement and test our software.
My perspective is that its not how good or bad the spec is, its what you do with the information that you have in order to translate it into a form that you can write correct software that meets the intent and (where possible) the letter of the spec.
I'm guessing that the OP phrased this as a leading question, but nonetheless, I'll take the bait. My gut reaction to that phrasing is to cringe at the word "handed".
I take that to imply a passive involvement on the part of the developer when in my experience, the (perhaps defacto) requirements discovery phase works best not when conducted in a manner employing rigid, constrained roles/partitions1, but rather allows for some proactive developers/business analysts/customers to wear more than one hat.
Clearly, your business customers are the experts in the concrete realizations/puzzle pieces/edge cases/last mile implementations presently utilized by the business. However, if they knew how to put the puzzle pieces together, or how to recognize and discard redundant puzzle pieces, they wouldn't be coming to us.
Obviously, the better and sooner the collaborative team gets to understand the puzzle, the better. However, I have often observed what someone here called "Document Driven Development" in which 50 page specifications completely miss the mark from the perspective of impacting the business, and could be be easily improved with a 5 page on-target, forest-recognizing substitution.
There's more than one way to understand the puzzle. And so I would like to see process dialog focused upon how well the puzzle is understood and not a CYA-like measures of how many (often fragile or irrelevant) requirements were pre-enumerated.
1Partitioning a task among multiple people occasions extra communication effort
— training and intercommunication.
-Fred Brooks.
Selected Mythical Man Month Chapter Outline
I have gotten some from others - but generally they are still not all that usable for some reasons or another.
i generally write my own requirements prior to doing work - that includes for personal projects, consulting and for my day jobs.
Naver. Wouldn't even recognize one if it were in front of me. One time in one tiny company we attempted to write specs based on a superficial understanding of some magazine articles, and it degenerated into an over-detailed disorganized wish list. I've worked for small-scale groups, maybe the only programmer or in a tiny entrepreneurial lone-cowboy-coder company, and in tiny groups resembling that (except for the business side) embedded in large companies. The whole concept of planning, methodologies etc has evaded me thus far! I suspect this was hurting my chances in the last job hunt.
I always recommend working with a functional specifications document that is agreed upon by all parties as to the features that constitute project completion, especially for large projects. Any features that are requested but not on that list are considered to be change requests that will impact the delivery date. This way, the customer can't come back to us and say "oh btw we want this feature too..." after we've already negotiated the delivery date, without having to renegotiate the date. In addition to covering your bottom line and rear, you also know exactly when a project is considered "finished".