Paul was the new man on the team. He was hired to manage quality assurance. His suggestions, although valid, were geared toward teams of hundreds of developers collaborating on millions of lines of code. We have six developers working on a few thousand lines of code. My unwillingness to build the infrastructure for a large organization was interpreted by Paul as a lack of commitment to quality. It was not a lack of commitment to quality but an acknowledgement of practical and pragmatic considerations.
First, there are always budgetary constraints. Most small companies do not have the budget of Microsoft, Autodesk, Intuit, or other large software companies. Pretending to be in that realm is a good way to exhaust needed capital before the product is complete. In that circumstance, all the quality assurance in the world will not get your product successfully to market. Second, a certain level of formality is required in large organizations or chaos will reign. However, a small company can dispense with some of that formality. One of the advantages of a small software company is being lean and mean. Don’t lose that advantage pretending to be a big company.
I could easily create the perfect product in the infinite universe, with unlimited venture capital and unbound resources. However, because most of us live in the real world, this is not an option—even for a large software company or institution. Before the project starts, evaluate your financial position and define a budget. When the budget is finalized, you can then plan. The proper balance and allocation of resources among development, quality assurance, and testing can only be decided then. Hopefully, you will have the resources to implement the perfect product in an infinite universe. If not, you now have a realistic plan for success that can be executed.
