Software code can get really complex and we all agree that complex code is harder to maintain and enhance. This leads to lower business value for the application as the inevitable changes required for the application to keep pace with a changing environment cost more and more to implement for a given function size.
Consequently, I was a little surprised to see the title, “Cozying up to Complexity,” at the head of a book review by Robert W. Lucky in the January 2017 edition of the IEEE Spectrum. Lucky reviewed the new book by Samuel Arbesman, “Overcomplicated.” Lucky identifies Arbesman’s three key drivers of increasing technological complexity: “accretion”, “interconnection”, and “edge cases”. Accretion is the result of the continual addition of functionality on top of and connecting existing systems. Connecting ever more systems leads to interconnection complexity. Edge cases are the rare but possible use cases or failure modes that have to be accounted for in the initial design or incorporated when they are discovered. Over time, these edge cases add a lot of complexity that is not apparent from majority uses of the system. Increased software complexity can be a problem for outsourcing software development because more complex code is more difficult to maintain and more difficult to enhance. This becomes a problem for software vendor management as costs go up due to reduced vendor productivity.
There are measurements and metrics for software complexity but Lucky reports that Arbesman’s suggested solutions for complexity including the novel idea that we should not take a physicists mathematical view to try to build a model. Instead, we should take a biologists view: record the complexity we find (e.g. in nature) and look for patterns that might repeat elsewhere. Arbesman does not necessarily see increased complexity as a bad thing.
If we accept that some level of complexity is a good and necessary thing to achieve the “magic” of current and future software capabilities, I wonder if there is a way to identify the point of maximum useful complexity? Perhaps “useful complexity” could be measured in function points per line of code? Too much complexity would be indicated by a low “useful complexity” value – trying to shoehorn too much functionality into too few lines of code. At the other end of the spectrum – what Arbesman might refer to as his edge cases – we might see too little functionality being delivered by too many lines of code.
My train of thought was as follows:
- A program with zero functionality (and zero function points) may have complexity but I’m going to exclude it.
- A program with 1 function point must have some lines of code and some small complexity.
- For a program with a reasonable number of function points, I (as a former ‘C’ programmer) could make the program more complex by reducing the number of lines of code.
- Adding lines of code could make the program less complex and easier to maintain or enhance by spreading out the functionality (and adding explanatory comments although these don’t usually count as lines of code) up to a certain point, after which diminishing returns would apply. The question is where is that point.
- It must also be true that there must be a certain complexity inherent in coding a certain number of function points. This implies a lower limit for the complexity given a fixed number of function points.
- This suggests that, for a given number of function points, there might be a non-linear inverse relationship between complexity and lines of code.
I’d welcome people’s ideas on this topic. Thoughts?