Ever had a sales person sell a feature that your product didn’t have? Unfortunately this has happened to me many times throughout my software engineering career. If you have experienced this, you have experienced a conflict that is happening throughout your entire system: the Consumer Provider Conflict.
Software Systems as Fractal Systems
First I need to show that a quality software system is fractal in design. Software systems are usually hierarchical: higher level “consumers” solving problems using lower level “providers”. In that system hierarchy, a fractal pattern of property/method shows up.
Starting at the top, the system solves specific problems. For example, a save button for your text document editor will convert your domain specific data into a markup format and save the data to disk. This is a very specific problem that has many steps.
At the lower end, code is created to solve general problems. From the example above, there would be a piece of code in your system that would save a string to a file by path. This low lever algorithm is a general purpose piece of code that would be used in many other places in your code.
General/Specific Problem Solving Paradox
The example above was only describing 2 dimensions, but we all know that software systems have many levels. This fact helps illustrate an interesting paradox:
No matter where you lookin in a system’s hierarchy, higher level code is solving specific problems while lower lever code is solving general problems.
This means that if you move your focus up, the code you were looking at before which looked like was solving specific problems now looks to be solving general problems. That lower level code that saves a string to a file, its using even lower level code that deals with byte management on disk, which makes the code that saves the string to a file look like its solving a specific problem.
Throw a dart anywhere in the hierarchy and the code above looks to be solving specific problems while the code below looks to be solving general problems. If you move down the hierarchy and look up, the nodes that you saw to be solving general problems now look to be solving specific problems.
But what’s even more interesting is that no matter where you are looking within the system hierarchy, there is a dynamic happening: there is an inherit conflict in problem solving between the higher level code and the lower level code.
Problem Solving Conflict
There is an inherit conflict within a fractal system such as the one described above:
Higher level entities (consumers) will want lower level entities (providers) to solve specific problems, while lower level entities will want higher level entities to solve general problems.
Back to our sales/engineering example: the sales person is at a higher level in the business. They are working with potential clients and helping them solve their specific issues. Engineers are at a lower level in the business, creating product that can solve many problems. The conflict comes when the sales person, rightfully representing their client, will champion their specific solutions while the engineer will reflect and push for the sales to adjust their solutions to use already created features.
In code, the tendency is for lower lever code to sway towards solving specific problems, thus making them less reusable. The conflict usually shows itself over time and due to the fact that one person (a software developer) is writing the code at every level of the system. The software developer is thinking like the sales person: we need to solve a specific problem.
Coding From The Bottom Up
The first principles I teach junior developers is Inversion of Control (IoC). If you are not familiar with IoC, you can read a great tutorial at TutorialsTeacher.
The specific part of IoC that I teach is to write code from the bottom up, not top down. This forces the developer to think about solving the lower level general problem solving code first, then work their way up to solving the specific problem that they have set out to solve.
Then next principal I teach is the Single Responsibility Principle. For junior developers, I’ll make then summarize the class and method. If the word “and” is in the description, then the code needs to be split up. This helps the developer think in creating code that solves general problems.
Unintended Consequences
There is one big issue with creating systems in the way described above: general problem solving never solves 100% of the potential problems. It’s more like 80%. Because nodes within a fractal system solves 80% of potential problems, then we get Pareto Principle effects at the system level. Issues like “20% of the code has 80% of the errors” or “80% of a certain piece of software can be written in 20% of the total allocated time.” Wikipedia.
Even though these are unwanted potential issues with a complex system, I believe currently there is no better way to build a complex system that is extensible and maintainable.
Overview
Within a fractal system, there is an inherited conflict between higher and lower level nodes: higher level nodes wants lower level nodes to solve specific problems and the lower level nodes want higher level nodes to solve general problems. This conflict is central to a developers growth in creating modular code that is of high quality.
LongLoft - Code Writer 