Wednesday 29 May 2013

Not Planning is for Losers

Only the ignorant don't plan their code pathways before they write them; perhaps only classes with getter and setter routines don't need to be planned.

The total number of pathways through a software system grow so quickly that it is very hard to understand their total number.

If a function X() with 9 pathways calls function Y() which has 11 pathways then the composition function XY() will have up to 9 x 11 = 99 possible pathways.

If function Y() calls function Z() with 7 pathways, then XYZ()  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 Assurance

Quality 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 Defective

If there are 10 pathways through a function then there there must be branching 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

Defects are generally caused either because of one of the following conditions:
  1. incorrect implementation of an algorithm
  2. missing pathways
  3. choosing the wrong pathway based on the variables
1) Incorrect algorithms will compute a wrong value based on the inputs.  The damage is local if variables are not involved, however, if the value is computed in a variable X then damage can happen throughout the scope that X is available. Example, bad decision at node 1 causes execution to flow down path 3 instead of 2.

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

When code with poor pathways gets to QA you have the following situation.  The program cruises down to point 5 where a calculation is wrong or an incorrect decision is taking which then leads to bad calculations. 

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
The longer it takes for someone to notice the defect or the further that point 5 is from point 9 in the code -- the longer and harder it will be to locate and fix the defect.

Defects that persist for a long time end up generating work-arounds in the code that can break when the original defect is repaired.  

In fact, 1 out of 7 defects being fixed will create a new one!

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 Plan

Whenever 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 Solutions

The 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 Solutions

All 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 Solutions

Many 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
Moo?

Want to see more sacred cows get tipped? Check out
Make no mistake, I am the biggest "Loser" of them all.  I believe that I have made every mistake in the book at least once :-)

References

No comments:

Post a Comment