A few years ago I wrote about the independent technical reviews any software project must regularly go through in order to make sure everything is under control. I even said recently that there is no excuse for not doing them. Moreover, the more we trust programmers, the higher the necessity to review their projects regularly. Here is a short summary of what a report from a reviewer must include.

I tried to touch on this subject in a few recent talks: Make Customers Trust You at BDMSummit 2017, How to Be Honest and Keep a Client at PMCon Kharkiv 2017, and How to Avoid Outsourcing Disaster at Kyiv Outsourcing Forum 2017. Also, there are a number of blog posts along the same lines, including Seven Deadly Sins of a Software Project, How to Avoid a Software Outsourcing Disaster, and Software Outsourcing Survival Guide. Here, finally, is a more or less complete list of things a good report must include.

Basically it’s a list of questions a reviewer must answer. When all the answers are collected, the report is ready. The most important questions are at the top.

• Is the release procedure documented, automated, and does it work?
• Do releases happen frequently, at least once a week?
• How big is the technical debt (the things that “eventually” should be fixed)?
• Is the delivery pipeline strong enough to reject mistakes?
• How clean is the code? How many anti-patterns appear?
• Are all bugs and features registered as tickets?
• Is the code base covered by unit tests, and is coverage visible?
• Are “Work for Hire” agreements signed with all developers?
• Are key architectural technical decisions documented?
• Is static analysis in place and mandatory for new changes?
• Is continuous integration in place, and are its reports taken into account?
• Is master branch read-only?
• Are programming metrics collected and regularly reviewed?
• Is the source code repository under the customer’s ownership and control?
• Is the requirements documentation short and up to date?
• Do key classes, methods and functions have in-code documentation?
• Is the source code repository garbage free?
• Are UI/UX interfaces documented?
• Are the production logs visible and regularly reviewed?
• How responsive is the team to the tickets?
• Does the revision control system have a clear history of documented changes?

Essentially, this is a very short compilation of the most important things that you can find in the CMMI. They require all this, and a large list of other things on top. But a small project doesn’t need everything that they ask you to have. My list is shorter and, I’m sure, will be just enough for most of you.

By the way, you can see the reports volunteers create for the participants of my Software Quality Award. They analyze open source projects and briefly report the problems they find. I believe that they are trying to answer exactly the same set of questions.