In 1975, Fred Brooks, a manager overseeing the team that was developing OS/360, an IBM operating system, wrote the book, “The Mythical Man-Month.” His observation was that if you add additional workers to a software project that is already behind schedule, you will inadvertently make it even later. The reason is that the engineers currently working on the project have to divert attention from their work to train new employees. In addition, the communication needed to incorporate additional software developers creates significant overhead that slows the pace of work.

Continuous QA Keeps Projects on Track

Quality assurance is critical to avoiding late software projects, the temptation to add additional staff, and running into Brooks’ Law. The reality is that projects that are running late rarely turn the corner and finish on time. Quality assurance that’s part of the project plan from the beginning (continuous testing) helps pinpoint problems in the beginning that would only grow more cumbersome and stubborn as the project develops.

Don’t Wait Until the End

Perhaps the biggest danger is allotting too much testing to the end of the project – the overhead of training and communicating is too great. Just like Brooks’ Law posits that additional software engineering resources slow down a project that’s already overdue, additional software testing resources will too. The same pitfalls of training and communication will befall your QA team.

Software testing also fits naturally at the end when the system is complete to ensure its viability and functionality, but it doesn’t belong only at the end. The alloted time for thorough testing at the end is invariably used up in the middle of project development. Team members need to test their work as it progresses. Waiting until the end means there won’t be enough time left to properly train testing staff and communicate testing procedures.

Brooks’ Law Still in Effect

Quality assurance should span the entire development life cycle, from the time the project is analyzed and requirements are gathered to the end stages. Since 1975, we’ve seen a tremendous amount of change in software development. Yet Brooks’ Law is still in effect after all these years. You can’t force software testing in at the end of a project. It must be baked in at the beginning and continuously emphasized as the project unfolds.