If function Y() calls function Z() with 7 pathways, then X∘Y∘Z() will have up to 693 = 9 x 11 x 7 pathways. The numbers add up quickly, for example a call depth of 8 functions each with 8 pathways means 10.7 million different paths; the number of possible pathways in a system is exponential with the total depth of the call tree.
Programs, even simple ones, have hundreds if not thousands (or millions) of pathways through them.
Negative vs Positive AssuranceQuality assurance can only come from the developers, not the testing department.
Testing is about negative assurance, which states that "I don't see anything wrong"; it doesn't mean that everything is correct, just that they can't find a problem.
Positive assurance which is guaranteeing that the code will execute down the correct pathways and only the developer can do that.
Quality assurance comes from adopting solid practices to ensure that code pathways are layed down correctly the first time
Any Line of Code can be Defectivebranching statements to be able to direct program flow down each of the pathways. Each pathway may compute variables that may be used in calculations or decisions downstream. Clearly, each downstream function can potentially have its behavior modified by any upstream calculation.
When code is not planned then errors may cause execution to compute a wrong value. If you are unlucky that wrong value is used to make a decision which may send the program down the wrong pathway.
If you are really unlucky you can go very far down the wrong pathways before you even identify the problem.
If you are really, really, really unlucky not only do you go down the wrong pathway but the data gets corrupted and it takes you a long time to recognize the problem in the data.
It takes less time to plan code and write it correctly than it takes to debug complex pathways.
Common Code Mistakes
- incorrect implementation of an algorithm
- missing pathways
- choosing the wrong pathway based on the variables
2) Missing pathways have to deal with conditions. If you have 5 business conditions and only 4 pathways then one of your business conditions will go down the wrong pathway and cause problems until you detect the problem. Example, there was really 5 pathways at node 1, however, you only coded 4.
3a) The last problem is that the base values are correct but you select the wrong pathway. This can lead to future values being computed incorrectly. Example: at node 10 you correctly calculate that you should take pathway 11 but end up going down 12 instead.
3b) You might also select the wrong pathway because insufficient information existed at the time that you needed to make a decision. Example: insufficient information at node 1 causes execution to flow down path 3 instead of 4.
The last two issuses (2 or 3) can either be a failure of development or of requirements. In both cases somebody failed to plan...
When Incorrect Code Gets to QA
However, you are only going to notice the problem when:
- Some tangible element is changed (i.e. screen, database, or report)
- Either QA or a customer notices the problem which actually occurs at point 9
This is why planning is critical, if it costs X effort to find the defect in development, it will cost 10 X effort to find the defect in QA, and 100 X to find the defect if your customer notices it.
What if it is too late to PlanWhenever you are writing a new section of code you should plan the code before you write it. Existing code can take advantage of inspections to locate and remove defects. Don't wait for defects to develop, proactively inspect all code, especially in buggy modules and fix all of the code pathways.
Code inspections can raise productivity by 20.8% and quality by 30.8%
Code SolutionsThe Personal Software Process (PSP) proposes that every code section should be planned before it is implemented. That means that you plan your code pathways using paper or a white board before using the keyboard. Ideally, you would spendpart of your day planning with your colleagues on how best to write your code pathways.
PSP can raise productivity by 21.2% and quality by 31.2%
If you insist on writing code at the keyboard then you can use pair programming to reduce errors. By having a second pair of eyes looking at your code algorithmic mistakes are less likely and incorrect decisions for conditions are looked at by two people; unfortunately, pair programming is not cost effective.
Pair Programming can raise productivity by 2.7% and quality by 4.5%
Studies confirm that code sections of high cyclomatic complexity have more defects than other code sections. At a minimum, any code section with high cyclomatic complexity should be planned by two or more people. If this is not possible, then reviewing sections of high cyclomatic complexity can reduce downstream defects.
Automated cyclomatic complexity analysis can raise productivity by 14.5% and quality by 19.5%
Design SolutionsAll large software projects benefit from planning pathways at the macroscopic level. The design or architectural planning is essential to making sure that the lower level code pathways will work well.
Formal architecture for large applications can raise productivity by 15.7% and quality by 21.8%
Requirements SolutionsMany pathways are not created in development but are an artifact of the requirements. If there is insufficient information to choose a proper pathway or there are insufficient pathways indicated then this is a failure of requirements. Here are several techniques to make sure that the requirements are not the problem.
Joint application design (JAD) brings the end-users of the system together with the system architects to build the requirements. By having end-users present you are unlikely to forget a pathway and by having the architects present you can put technical constraints on the end-users wish list for things that can't be built. The resulting requirements should have all pathways properly identified along with their conditions.
Joint application design can raise productivity by 15.5% and quality by 21.4%
Requirements inspections are the best way to make sure that all necessary conditions are covered and that all decisions that the code will need to make are identified before development. Not inspecting requirements is the surest way to discovering that there is a missing pathway or calculation after testing.
Requirement inspections can raise productivity by 18.2% and quality by 27.0%
Making sure that all pathways have been identified by requirements planning is something that all organizations should do. Formal requirements planning will help to identify all the code pathways and necessary conditions, however, formal requirements planning only works when the business analysts/product managers are skilled (which is rare :-( ).
Formal requirements analysis can raise productivity by 16.3% and quality by 23.2%
Other articles in the "Loser" series
Want to see more sacred cows get tipped? Check out
- Comments are for Losers
- Defects are for Losers
- Debuggers are for Losers
- Efficiency is for Losers
- Testing departments are for Losers
- Gilb, Tom and Graham, Dorothy. Software Inspections
- Jones, Capers. SCORING AND EVALUATING SOFTWARE METHODS, PRACTICES, AND RESULTS. 2008.
- Radice, Ronald A. High Quality Low Cost Software Inspections.