Today a second developer came and asked me to peer review their software release documentation. I marked up his hard copy with a lot of red marks. And I guess I should feel good that the peer review is adding a lot of value towards generating a high-quality release. But an ideal scenario would be a minor correction here or there in during a peer review, not a massive rewrite.Here are some of the problem I found in the software release documentation:
- Wrong build number listed
- Wrong file timestamp listed
- Not documenting special circumstances of release
- Filling out sections of the document that our customer reserves for their use
- Filling out other sections incorrectly, violating customer policy
These are the basics that we should always get right. Perhaps developers and configuration management know they can be sloppy since we have a process of review that catches most of these problems. Or maybe people have Thanksgiving fever and just want to slap something together and go on vacation.
I know I personally perform quality control on documents I generate before I pass them on to others for review. But that's just me. Maybe that's what our process is really all about. No matter what the skill or level of effort performed by the staff, the process still is set up to indentify and resolve problems before we ship stuff out to our customers. Now this usually only works on big projects with big budgets. If I worked at a startup, I imagine there would be minimal process and more individual responsibility to get things right the first time.
