Tips and Tricks – Limiting Function Complexity shall be a Requirement!

I have recently become interested in brain training applications that are designed to test and improve mental speed, attention, memory, flexibility and problem solving. Despite believing that I have a superb and extraordinary memory, I am constantly surprised at how poorly I perform in the memory games. One of my favorite games displays a grid with squares that light up in a random pattern. The game provides a short time period to memorize the pattern and then clears the grid. The player has to then click on the squares and recreate the pattern. When the pattern contains ten or less squares I’m an absolute champion but as soon as it becomes eleven or greater, my consistency and success rate drop like a rock.

The memory game is a clear demonstration that despite believing we are super human and capable or remembering everything, we are in fact, quite human. What does this have to do with embedded software? The memory game shows that a human can easily handle and keep track of 7 – 10 items at a time. Writing complex functions with more than ten branches means that a developer may suddenly start to struggle to remember everything that is happening in that function. This is an important limit and it tells developers that in order to minimize the opportunity for bugs to creep into their software, the function should be limited to a complexity less than ten.

Limiting function complexity is one of the best ways to make sure that the software components that make up the entire system do not exceed a certain level of complexity.  There are many different ways in which an engineer can measure the function complexity.  The measurement that I am the fondest of is Cyclomatic Complexity.  There are a number of tools on the market that will analyze each function within a program and then provide a number that represents how complex the function is.  What the measurement is doing is determining the number of linearly independent paths through the function.  In order to keep track (mentally) of everything that is going on in the function, the resultant number should be kept below 10.

The memory game is also a good indicator that developers should not design by coding. Time should be taken to draw out an architecture and what the application is doing before implementation. Otherwise, the chances are that some key information will go missing from the developers local RAM and an intense debugging session or project delays will ensue.