|
I don't, because of my laziness. 
Who needs them anyways?
CLR: Removes tough Java-based stains fast!
|
|
|
|
|
Anyone who writes code that people uses for years and need more developers who will support it. Anyone whose software is being paid by large number of customers.
Laziness may be ok for small to medium projects and for newbie developers, but not for large projects and professional developers.
A good documentation is necessary for large team and high customer base. Writing a good specs may take quite a substantial time and effort, but is justifiable, necessary and a important tool to maintain the code quality.
|
|
|
|
|
1. I'm one person.
2. My app isn't for developers. It's in fact ridiclously easy to pick up.
3. My code is medium-small. My code is clean and elegant to.
CLR: Removes tough Java-based stains fast!
|
|
|
|
|
clean and elegant code which is self explanatory (easy to pick up) is the best specs .
Also for small scripts or small tools that I write for myself or my friends, I don't worry about documentation. But for utility class that I write for open source, or for commercial application documentation is a must must thing.
Also the whole survey is amazing, as quality and specs writing is an ongoing process, those that don't change are dead things. The basics of Extreme programming is improving the quality of documentation, specs, etc. as an when required in an ongoing process. As per me spending too much dedicated time for specs writing before or after the project is a wastage of time and effort.
|
|
|
|
|
I think many are missing the idea however of what a 'spec' really is.
The spec is NOT there to help someone understand the code. Its there to help someone understand what the code is supposed to DO. The design docs and code comments are there to help someone understand the code.
The spec is what marketing uses to write marketing stuff.. (i.e. The product will do this, that and the other thing.) and what the designers use to make sure that the product DOES what it needs to do (and what marketing is telling people that it will do).
Who needs a spec? Anyone with a product with more than, say, three major features does IMHO.
Without a spec how do you know when you are done? Now, the questions begs asking, if you are a small (lone) developer, does the spec always need to be written down? YES, I think so. Just like you should always have a habit of writing down your own personal goals and objectives at some point (your own life spec) you should do it for your own development time.
|
|
|
|
|
And my code does what it does.
Dim SomethingAboveMyHead As LightBulb
|
|
|
|
|
Obviously you're so lazy no company would employ your services.
I would have thought the minimum spec was what the customer wanted to achieve (a functional spec).
|
|
|
|
|
especially in the "continuous" category...
Wouldn't it be interesting if we took the same approach, and "spec'd" or "designed" our life plan.
Marc
|
|
|
|
|
Have you talk to one of those guys at the IDS company? Or any personal financial planner for that matter.
|
|
|
|
|
You plan your life? 
Citizen 20.1.01 'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
|
|
|
|
|
lets hire one of those guys who plan for others life 
|
|
|
|
|
Can someone clarify the difference? 
I'm not up on my business buzzwords. 
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
For my projects, I write steps to validate a requirement as specification. A requirement is a goal statement that may be translate into multiple specifications. A spec is a group of contraints and/or process that satisfied a requirement and it is the first technical and logical steps that is verifiable and testable regardless of technology. A desin is a translation of a spec in term of behavior and data management with technolog, domain, system and language dependency.
|
|
|
|
|
Interesting. I think I use the term "design" more for what you call a specification, and what you call "design" I call implementation.
"Requirements" is obvious, but I don't usually have a formal set of requirements when working on my projects (I'm just a one-man company). That pretty much gives me the freedom to change the requirements as I go. Of course I always have a general overall goal I'm trying to achieve.
Logan
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
To me, there are distinction between requirement, specification and design. A customer or an end user gives me a story of what they wanted accomplish. This is in normal English, may contains technical data and hinted information on how they want the system to behave, but they are just a story. This story is broken down to quantifiable and testable requirements. A specification sets boundary, limitations and stated specific behavior that is verifiable and measurable or countable against a requirement. A spec doesn't tell how to manage structures to organize data, events, responsibilities, collaborations and where the data are to be store. A design will tell how to accomplish that using specific technology. I use the term "implement" to translate the design to code.
|
|
|
|
|
I use it to mean a concrete description of what needs to be done, for instance ("Create a form using XAML and VB.NET that will display initially with a size matching 60% of the user's available screen space and centered on the primary screen. A labeled text entry field will be positioned at (10,10) and validated via...)
Somewhere between design (which might say, "a form matching the attached layout, allowing input with the following constraints, with each change triggering a refresh of the displayed model") and implementation (which consists of the actual form and associated behaviors).
Citizen 20.1.01 'The question is,' said Humpty Dumpty, 'which is to be master - that's all.'
|
|
|
|
|
I see. I guess that explains why I've never done one myself. I don't really need to tell myself to "put a text entry field on the form at 10,10--I just do it.
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
Simple...
Spec -> Design
What -> How
|
|
|
|
|
So who comes up with the spec and what's that process called?
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
Typically its the marketing department, or the business development department and it is called requirements gathering. The deliverable form here is usually something like an MRD (Marketing Requirements Document) or a BRD (Business Requirements Document) that says 'there is a market opportunity that needs to be filled and if we are to do the work to fill it we need a product in the market by this date that had features x, y, and z).
|
|
|
|
|
Fascinating.
“Time and space can be a bitch.”
–Gushie, Quantum Leap
{o,o}.oO( Looking for a great RSS reader? Try FeedBeast! )
|)””’) Built with home-grown CodeProject components!
-”-”-
|
|
|
|
|
I voted for "Continuously during the lifetime of the project"
I write specs as I need them (ie, I have to show them to someone) because I'm a single developper, so all my projects are small.
My methodolgy for project management, is an accelerated form of "code'n'fix". Except I know what the project's goal is, which isn't always the case with regular "code'n'fix".
For starters, I talk to the person who asked something to my manager, with a notebook and a pen, to figure out what they need.
Once I'm sick of talking to them, I go to my office and start coding. Once in a while, a question comes up, so I pick up the phone or send an e-mail (depending on how urgent and complicated the question is, and how clueless the "client" is). After a couple weeks (or a couple days), I submit a program. They say it matches exactly what they need. After a couple tries using it, they call back asking for some changes, and here we go again.
Yeah, I guess that should mean there's not much specs in the end, but before I call the project "finished", I always write a Word document explaining why I made the project and how to use it. And I add in the appendix some emails and some drawings just to pretend there was some planning involved. That's the closest to specs I'll ever produce for that project.
And I actually think that it's not that bad, at least for small projects where there's no communication between developpers involved
"Computer Science is no more about computers than astronomy is about telescopes." - Edsger Dijkstra
|
|
|
|
|
What is a small project. Every time I hear that somebody wants me to work on a small project, I turn and run. Most times the small projects take up all your time.
Hogan
|
|
|
|
|
To me, a small project is 1 week or less. You're right in that it makes one more project for me to maintain (bug fix, change request, and all that), but I'm lucky enough not to suffer too much from scope creep. JUST KIDDING! Of course there's scope creep. I just try to ignore it.
"Computer Science is no more about computers than astronomy is about telescopes." - Edsger Dijkstra
|
|
|
|
|
right hogan..
usually small projects are planned to be over in lesser than a month but alas! they do not....
Ashish Sehajpal
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
