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 -
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; -
A 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;Gary Wheeler wrote:
A bitter, bitter pill indeed
Well, medicine that cures doesn't usually taste very good. And having taken the medicine, I can now see a mile away when things are going downhill and either try to correct it early or get out of the way sooner. A friend of mine who has worked at the same company for almost 20 years expressed his surprise that I identified so early the hidden agenda of the new management, which they finally disclosed a year later after a lot of "we're 100% behind you" doubletalk. And the sad thing is? It took me less than 15 minutes in the presence of the then new senior manager to see through his bullshit. Well, that and having done some basic googling to read about his background.
Gary Wheeler wrote:
Too bad we can't strap management down to a table and forcibly inject them with some reality...
We could if we had the guts to go on strike instead of constantly grumbling to ourselves. Though I think my thinking is myopic. There are definitely more effective ways of communicating other than ultimatums, but having an "open and honest" meeting with management just doesn't often seem possible because their is no openness and honesty on their side. And the funny thing is, this pervades every social organization I've worked with, whether it's board members, faculty, committee leaders, etc. The most stark contrast was a guy who wanted a committee to look into alternative tuition payment plans for parents at my son's school, propounding the ideas of "open and transparent." When it came to putting together the final report to go to the school board, the very people that worked on gathering information for the report were not allowed to see the report. So much for "open and transparent." Needless to say, I had a cow. Apologies for the longwinded response! Marc Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog -
Gary Wheeler wrote:
A bitter, bitter pill indeed
Well, medicine that cures doesn't usually taste very good. And having taken the medicine, I can now see a mile away when things are going downhill and either try to correct it early or get out of the way sooner. A friend of mine who has worked at the same company for almost 20 years expressed his surprise that I identified so early the hidden agenda of the new management, which they finally disclosed a year later after a lot of "we're 100% behind you" doubletalk. And the sad thing is? It took me less than 15 minutes in the presence of the then new senior manager to see through his bullshit. Well, that and having done some basic googling to read about his background.
Gary Wheeler wrote:
Too bad we can't strap management down to a table and forcibly inject them with some reality...
We could if we had the guts to go on strike instead of constantly grumbling to ourselves. Though I think my thinking is myopic. There are definitely more effective ways of communicating other than ultimatums, but having an "open and honest" meeting with management just doesn't often seem possible because their is no openness and honesty on their side. And the funny thing is, this pervades every social organization I've worked with, whether it's board members, faculty, committee leaders, etc. The most stark contrast was a guy who wanted a committee to look into alternative tuition payment plans for parents at my son's school, propounding the ideas of "open and transparent." When it came to putting together the final report to go to the school board, the very people that worked on gathering information for the report were not allowed to see the report. So much for "open and transparent." Needless to say, I had a cow. Apologies for the longwinded response! Marc Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My BlogNo apology necessary. You and I have been around the block enough times that our noses have been rubbed in all possible flavors of organizational dysfunction. My goal has become one of remembering that this is how I earn my living, rather than this is how I live my life.
Marc Clifton wrote:
There are definitely more effective ways of communicating other than ultimatums, but having an "open and honest" meeting with management just doesn't often seem possible because their is no openness and honesty on their side.
True. My boss is reasonably honest, and his boss is as well. Farther up the chain we have communication problems. I work for a hardware company managed by hardware engineers. They distrust software engineers because most of us don't express ourselves very well, and they extend that distrust to all of us by default.
Software Zen:
delete this; -
No apology necessary. You and I have been around the block enough times that our noses have been rubbed in all possible flavors of organizational dysfunction. My goal has become one of remembering that this is how I earn my living, rather than this is how I live my life.
Marc Clifton wrote:
There are definitely more effective ways of communicating other than ultimatums, but having an "open and honest" meeting with management just doesn't often seem possible because their is no openness and honesty on their side.
True. My boss is reasonably honest, and his boss is as well. Farther up the chain we have communication problems. I work for a hardware company managed by hardware engineers. They distrust software engineers because most of us don't express ourselves very well, and they extend that distrust to all of us by default.
Software Zen:
delete this;Gary Wheeler wrote:
They distrust software engineers because most of us don't express ourselves very well, and they extend that distrust to all of us by default.
I've seen that many times. An amusing story (and then I'll go away, because I do have to meet my client shortly!) - years and years ago (8 bit microprocessor era) the new PC boards came in for a camera controller and the software, which ran fine on the hand-wired prototype, would randomly crash on the new board. The hardware guy didn't have much respect and insisted it was a software glitch. After some poking around, I wrote a simple test loop and showed him with an oscilloscope that there was a race condition in flipping the bit for the multiplixer that converted two 8 bit "outs" to a 16 bit address. I won his undying respect. The amusing thing is, the reason for the race condition was that the low/high byte line on the prototype was a wire about 8 inches long, and on the printed circuit board, it was a couple centimeters. That .75 nanoseconds made all the difference between stable vs. sometimes flaky addressing. Yikes. Marc
Testers Wanted!
Latest Article: User Authentication on Ruby on Rails - the definitive how to
My Blog -
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
Spot on! :cool:
-
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:
Personally I like it.
You're a monster... ;P I don't like doing documentation, specially at the end of the project given that is too tedious, however when I have to do it, I try to do it along with the project so the effort is distributed and, hopefully, less painful.
CEO at: - Rafaga Systems - Para Facturas - Modern Components for the moment...
-
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
Hi, I love writing and as a project manager i believe that documentation is one of the crucial phase of software development. However many small and mid sized companies avoid this as it takes considerable time and efforts before begining the actual development process. To cut the cost, they prefer very brief writeups and opt for in line comments in the software code. later on it becomes difficult to maintain the software due to lack of proper documentation. To make the development phase interesting, it is necessary that the entire specification be documented keeping scope of 10% for plugging in additional requirements or enhancements for maintaining quality of output, flow charts be prepared, schedule plans be drafted and handed to team. Every team member must proceed according to these documents by reviewing at regular periods during the development phase to ensure that output delivered in not different than the requirements given. Documentation prior, during and post project completion is thus very important. it helps the new team also who will be working on it after a period of time for providing support and maintenance.