This week's survey: What is your favourite phase of software development?
-
grralph1 wrote:
1. Documentation means that you have finished the product. (Hopefully on time and within buget.)
Absolute codswallop, balderdash and piffle. Documentation should be written before, during and after the software. It's as much part of the software development as the actual source code, and should not be relegated to the post build phase of the project.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier:thumbsup: If you don't document as you go along, you won't go back and do it (most of the time you aren't given any time to go back and do documentation once the product is out).
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
... and we'll know the difference between know, now and no.
Reality is an illusion caused by a lack of alcohol
-
I'm having a bad day. I've just sent an e-mail where I spelt 'fault' as 'thought'. Who was it that said spelling mistakes are allowed after Lunch?
PB 369,782 wrote:
Who was it that said spelling mistakes are allowed after Lunch?
Some drunk with a Hungarian name ;P
Reality is an illusion caused by a lack of alcohol
-
It has been noted that there is no radio button for "Documentation" on the list for the favourite phase of software development survey. (This weeks.) Most hate it anyway and some would argue that it isn't development period. Personally I like it. It is not as enjoyable as the challenging bits, but; 1. Documentation means that you have finished the product. (Hopefully on time and within buget.) 2. It is still fresh in your head.(Therefore Easy to do without annoying errors and ennoying look ups.) 3. It is easy, boring, relaxing after all the hard yakka and not demanding in anyway at all. 4. It helps you later when changes have to be made. (Speeds up review and familarisation.) 5. Looks pretty in the app and hopefully limits support queries. 6. Lets you say check the help and the documentation, it is all explained there. Sometimes I am as pleased with the documentation as I am with the code. It is part of the whole process to me. When other people do the documntation, it is often lacking or just incorrect. I know that I am going to be flamed for this post, but I am also coming from a lone wolf perspective. I like the manuals to be integrated into the application. I am not as good at within code comments though and always regret this. Documentation is great because it is the end, the finalisation of an extensive effort. I now often augment the documentation with short videos. Documentation isn't my favourite part of development, but it comes close to it. My most hated part of development is repartition. Comments please....
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
-
grralph1 wrote:
1. Documentation means that you have finished the product. (Hopefully on time and within buget.)
Absolute codswallop, balderdash and piffle. Documentation should be written before, during and after the software. It's as much part of the software development as the actual source code, and should not be relegated to the post build phase of the project.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easierNak Pete Love the word piffle especially though. I do flow diagrams and and quizicle documents "before" to get feedback about what they actually want. I don't consider this documentation, although it may be included in it at the end. Whenever I do stuff "during" I always regret it as it usually has to be changed or more often completely redone at the end. Working alone means that I only have to note things for myself and this is not really documentation. You are probably correct when working in a team environment. For me it is always done at the completion of the project. The Help, the user manual and the engineer manual. I have done this "during" in the past and it has always caused me grief because, change is the way we make it better. ....and like Nagy said, "Oh yeh! Next you're going to be saying we should know what the software is going to do before we write it. ". When I have worked with big teams, my stuff was still ophaned off under contract so that the situation was the same.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
-
:thumbsup: If you don't document as you go along, you won't go back and do it (most of the time you aren't given any time to go back and do documentation once the product is out).
The universe is composed of electrons, neutrons, protons and......morons. (ThePhantomUpvoter)
-
Personally I think they ought to have a favorite Frank Zappa quote survey mine would be; Stupidity is the basic building block of the universe. But they that's just me. Ain't got any idea why Frank Zappa came to mind?
VS2010/Atmel Studio 6.1 ToDo Manager Extension Some days, it's just not worth chewing through the restraints.
There are lots of them Mike. The stupidity quote came from the question of what is the most abundant thing in the universe. Unfortunately it didn't turn out to be hydrogen. There are a few on CP sigs now. Chew through them tonight Mike
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
-
grralph1 wrote:
When other people do the documntation anything, it is often lacking or just incorrect.
Seriously, I often feel like I should just do everything myself.
That's how I prefer to work. My most satisfying projects have been like that.
-
It has been noted that there is no radio button for "Documentation" on the list for the favourite phase of software development survey. (This weeks.) Most hate it anyway and some would argue that it isn't development period. Personally I like it. It is not as enjoyable as the challenging bits, but; 1. Documentation means that you have finished the product. (Hopefully on time and within buget.) 2. It is still fresh in your head.(Therefore Easy to do without annoying errors and ennoying look ups.) 3. It is easy, boring, relaxing after all the hard yakka and not demanding in anyway at all. 4. It helps you later when changes have to be made. (Speeds up review and familarisation.) 5. Looks pretty in the app and hopefully limits support queries. 6. Lets you say check the help and the documentation, it is all explained there. Sometimes I am as pleased with the documentation as I am with the code. It is part of the whole process to me. When other people do the documntation, it is often lacking or just incorrect. I know that I am going to be flamed for this post, but I am also coming from a lone wolf perspective. I like the manuals to be integrated into the application. I am not as good at within code comments though and always regret this. Documentation is great because it is the end, the finalisation of an extensive effort. I now often augment the documentation with short videos. Documentation isn't my favourite part of development, but it comes close to it. My most hated part of development is repartition. Comments please....
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
-
It has been noted that there is no radio button for "Documentation" on the list for the favourite phase of software development survey. (This weeks.) Most hate it anyway and some would argue that it isn't development period. Personally I like it. It is not as enjoyable as the challenging bits, but; 1. Documentation means that you have finished the product. (Hopefully on time and within buget.) 2. It is still fresh in your head.(Therefore Easy to do without annoying errors and ennoying look ups.) 3. It is easy, boring, relaxing after all the hard yakka and not demanding in anyway at all. 4. It helps you later when changes have to be made. (Speeds up review and familarisation.) 5. Looks pretty in the app and hopefully limits support queries. 6. Lets you say check the help and the documentation, it is all explained there. Sometimes I am as pleased with the documentation as I am with the code. It is part of the whole process to me. When other people do the documntation, it is often lacking or just incorrect. I know that I am going to be flamed for this post, but I am also coming from a lone wolf perspective. I like the manuals to be integrated into the application. I am not as good at within code comments though and always regret this. Documentation is great because it is the end, the finalisation of an extensive effort. I now often augment the documentation with short videos. Documentation isn't my favourite part of development, but it comes close to it. My most hated part of development is repartition. Comments please....
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
The phase where management is supporting the effort, not working against you. The phase where the company says "oh, let's give you the newest and best-est hardware and tools so we can have a really productive environment. The phase where management says "let's use some professional bug tracking and testing software rather than that crapware called BugZilla" The phase where management says "we will NOT use SharePoint" The phase where management says "documentation and testing is vital to our success, so we're allocated extra time and budget to make sure everything is as accurate and up-to-date as possible and thoroughly tested. The phase where management says "the fact that we're behind schedule and have a lot of bugs in not your fault, it's my fault. I am failing at managing this project properly." Oh wait... Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog -
I use to be P0mpeyboy3 or PB3 for short. Now I use temp e-mail to sign-up which means I forget my e-mail everytime I reset my machine which has led me to have a succession of different usernames. To make it easier for the rest of you to identify me and as a nod to the amount of accounts I now have had in the past I used the random number at the end. The plan is when I change again I can just change the number and the rest of you will still no who I am.
-
It has been noted that there is no radio button for "Documentation" on the list for the favourite phase of software development survey. (This weeks.) Most hate it anyway and some would argue that it isn't development period. Personally I like it. It is not as enjoyable as the challenging bits, but; 1. Documentation means that you have finished the product. (Hopefully on time and within buget.) 2. It is still fresh in your head.(Therefore Easy to do without annoying errors and ennoying look ups.) 3. It is easy, boring, relaxing after all the hard yakka and not demanding in anyway at all. 4. It helps you later when changes have to be made. (Speeds up review and familarisation.) 5. Looks pretty in the app and hopefully limits support queries. 6. Lets you say check the help and the documentation, it is all explained there. Sometimes I am as pleased with the documentation as I am with the code. It is part of the whole process to me. When other people do the documntation, it is often lacking or just incorrect. I know that I am going to be flamed for this post, but I am also coming from a lone wolf perspective. I like the manuals to be integrated into the application. I am not as good at within code comments though and always regret this. Documentation is great because it is the end, the finalisation of an extensive effort. I now often augment the documentation with short videos. Documentation isn't my favourite part of development, but it comes close to it. My most hated part of development is repartition. Comments please....
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
Being paid.
-
Nak Pete Love the word piffle especially though. I do flow diagrams and and quizicle documents "before" to get feedback about what they actually want. I don't consider this documentation, although it may be included in it at the end. Whenever I do stuff "during" I always regret it as it usually has to be changed or more often completely redone at the end. Working alone means that I only have to note things for myself and this is not really documentation. You are probably correct when working in a team environment. For me it is always done at the completion of the project. The Help, the user manual and the engineer manual. I have done this "during" in the past and it has always caused me grief because, change is the way we make it better. ....and like Nagy said, "Oh yeh! Next you're going to be saying we should know what the software is going to do before we write it. ". When I have worked with big teams, my stuff was still ophaned off under contract so that the situation was the same.
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
grralph1 wrote:
The Help, the user manual and the engineer manual.
That's only one part of the documentation. Your problem here is your lack of upfront clarification as to what documentation is. Where do you keep your acceptance criteria? Where's your design? Where are your use cases? I could go on - and frequently do - but you get the idea.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
grralph1 wrote:
1. Documentation means that you have finished the product. (Hopefully on time and within buget.)
Absolute codswallop, balderdash and piffle. Documentation should be written before, during and after the software. It's as much part of the software development as the actual source code, and should not be relegated to the post build phase of the project.
I was brought up to respect my elders. I don't respect many people nowadays.
CodeStash - Online Snippet Management | My blog | MoXAML PowerToys | Mole 2010 - debugging made easier -
It has been noted that there is no radio button for "Documentation" on the list for the favourite phase of software development survey. (This weeks.) Most hate it anyway and some would argue that it isn't development period. Personally I like it. It is not as enjoyable as the challenging bits, but; 1. Documentation means that you have finished the product. (Hopefully on time and within buget.) 2. It is still fresh in your head.(Therefore Easy to do without annoying errors and ennoying look ups.) 3. It is easy, boring, relaxing after all the hard yakka and not demanding in anyway at all. 4. It helps you later when changes have to be made. (Speeds up review and familarisation.) 5. Looks pretty in the app and hopefully limits support queries. 6. Lets you say check the help and the documentation, it is all explained there. Sometimes I am as pleased with the documentation as I am with the code. It is part of the whole process to me. When other people do the documntation, it is often lacking or just incorrect. I know that I am going to be flamed for this post, but I am also coming from a lone wolf perspective. I like the manuals to be integrated into the application. I am not as good at within code comments though and always regret this. Documentation is great because it is the end, the finalisation of an extensive effort. I now often augment the documentation with short videos. Documentation isn't my favourite part of development, but it comes close to it. My most hated part of development is repartition. Comments please....
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
We did quite a big research around the problems with documentation. Here I mean documentation for end-users, not the code. It seemed like everyone is struggling with creating such things. It is hard to create budget around it, yet it became standard, to have documentation part of handover. The usual PDFs (with screenshots) or screencasts are pretty time consuming to create and then update. Reusability is almost non. So we had to develop our own tool, that will help us to tackle all of these and more issues. And that is why we have built http://inlinemanual.com works for anything using HTML and running in browser :) So even during development of new features devs are able to create documentation in few minutes. Or at least a stub version that can be later edited and extended by technical editors.
-
It has been noted that there is no radio button for "Documentation" on the list for the favourite phase of software development survey. (This weeks.) Most hate it anyway and some would argue that it isn't development period. Personally I like it. It is not as enjoyable as the challenging bits, but; 1. Documentation means that you have finished the product. (Hopefully on time and within buget.) 2. It is still fresh in your head.(Therefore Easy to do without annoying errors and ennoying look ups.) 3. It is easy, boring, relaxing after all the hard yakka and not demanding in anyway at all. 4. It helps you later when changes have to be made. (Speeds up review and familarisation.) 5. Looks pretty in the app and hopefully limits support queries. 6. Lets you say check the help and the documentation, it is all explained there. Sometimes I am as pleased with the documentation as I am with the code. It is part of the whole process to me. When other people do the documntation, it is often lacking or just incorrect. I know that I am going to be flamed for this post, but I am also coming from a lone wolf perspective. I like the manuals to be integrated into the application. I am not as good at within code comments though and always regret this. Documentation is great because it is the end, the finalisation of an extensive effort. I now often augment the documentation with short videos. Documentation isn't my favourite part of development, but it comes close to it. My most hated part of development is repartition. Comments please....
"Rock journalism is people who can't write interviewing people who can't talk for people who can't read." Frank Zappa 1980
I enjoy it too finished the thing! I am under the impression I was odd :)
-
The phase where management is supporting the effort, not working against you. The phase where the company says "oh, let's give you the newest and best-est hardware and tools so we can have a really productive environment. The phase where management says "let's use some professional bug tracking and testing software rather than that crapware called BugZilla" The phase where management says "we will NOT use SharePoint" The phase where management says "documentation and testing is vital to our success, so we're allocated extra time and budget to make sure everything is as accurate and up-to-date as possible and thoroughly tested. The phase where management says "the fact that we're behind schedule and have a lot of bugs in not your fault, it's my fault. I am failing at managing this project properly." Oh wait... Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My BlogWhat are you taking, and why didn't you bring enough to share?
Software Zen:
delete this; -
What are you taking, and why didn't you bring enough to share?
Software Zen:
delete this;Gary Wheeler wrote:
What are you taking, and why didn't you bring enough to share?
Only a dose of reality. ;) Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog -
Gary Wheeler wrote:
What are you taking, and why didn't you bring enough to share?
Only a dose of reality. ;) Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My BlogA bitter, bitter pill indeed :sigh: . Too bad we can't strap management down to a table and forcibly inject them with some reality...
Software Zen:
delete this;
