Time, cost, quality. Pick two? I say, "pick one": Focus on quality. Focus on quality as a way to optimise time and cost.
Software projects with quality as an afterthought can end up costing a lot more and taking much longer than they should. Software is complex. Reworking defective software is costly. "Done once, done right" is better.
Procedures relating to building, testing and installing a company's software shouldn't just be stored in an employee's head. Business owners really should demand that all such procedures form part of the company's inventory. But writing documents with long procedures isn't ideal. Ideal is where each task has been automated and requires just one manual step to invoke. The ROI can occur after only the second run of the automated procedure! No need to have someone labor through a long list of manual steps. No need to perform a detailed audit to ensure a procedure was correctly followed.
There's a lot to be gained by aiming for "as simple as possible". Every extra line of code could be a source of a bug. Every extra line of code will impede future efforts to modify the software. Guidelines such as each class should be responsible for just one thing help.
I take a lot of care in naming variables and functions. The name should make it obvious to the reader what it represents or what it does.
Sinful:
if (x) { do_y(); }
Better:
if (afterburner_requested) { fire_afterburner(); }
Studies (and common-sense) indicate that the earlier a defect is found (and corrected) the lower the cost.
Low cost: | add a line of code, discover that it causes a test to fail and fix it within the next minute. |
High cost: | write a mound of code, rush it through incomplete in-house testing, deal with a mountain of customer complaints. |
Testing can be put first. It doesn't need to be left to last when it may not be given the attention it requires. Having tests up-front clarifies what is required and a software developer should focus on the simplest solution to get the tests to pass.
Avoid manual testing. If a test is worth doing, then automate it so that it can be rerun (and easily adapted if required). Quality systems require specification of essential components, and a test script is a precise description of what the software has to do. Automated tests, with their quick turn-around, allow defects to be found and corrected as soon as possible.
I had to learn to fight my urge to test some things manually. If something can be tested manually in five steps, with a suitable test library it can be done with five function calls (probably less if the three or so setup functions repeated in many test cases are factored out).
Last update: 21 June 2014