Documentation is definitely great in volume but keeping the quality is also if not more important. So I have two questions, are all four of these separate documents, and separate from the code?
2 and 3 seem like they could be combined, and the detail at which 4 goes into seems like it would be more useful as comments in the /** */ fashion.
I am a Software Dev girl who loves Uncle Bob, is drawn to the human side of software development and clean coded applications, and enjoys acting as a liaison between the business and tech.
Yes, everything is separate. Some projects require even more documents. I understand the value of good documentation, but it's more about the process here. I remember writing high-level design, software system design and then describing the actual changes.
It'll be hard without a design - the think before implementation is important, but if the design has to be rewritten every time we miss the point...?
I believe that we can write 2 and then extend it to the new document by adding extra changes eventually. (You know, deliver 2 and 2-based 3 or 3 and 3-based 4) I never read any documentation, but the code isn't self-documenting itself either. It'll require the contribution of every developer.
The documentation is always written quite early and then we need to rewrite it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Documentation is definitely great in volume but keeping the quality is also if not more important. So I have two questions, are all four of these separate documents, and separate from the code?
2 and 3 seem like they could be combined, and the detail at which 4 goes into seems like it would be more useful as comments in the
/** */
fashion.Yes, everything is separate. Some projects require even more documents. I understand the value of good documentation, but it's more about the process here. I remember writing high-level design, software system design and then describing the actual changes.
It'll be hard without a design - the think before implementation is important, but if the design has to be rewritten every time we miss the point...?
I believe that we can write 2 and then extend it to the new document by adding extra changes eventually. (You know, deliver 2 and 2-based 3 or 3 and 3-based 4) I never read any documentation, but the code isn't self-documenting itself either. It'll require the contribution of every developer.
The documentation is always written quite early and then we need to rewrite it.