It is a gift to be simple

One of my favorite shows from the early 2000s is a British show, Junkyard Wars. It was called Scrapheap challenge there. The premise of the show is there are 2 teams tasked with building a specialized machine out of items in a big junkyard to help complete a task. The teams consist of 1 expert and three regular team members. A task could be building a machine to knock down a wall.
This was my favorite episode from the UK series.
One team made a hydraulic set of jaws on a manual crane, which they called The Muncher. The Muncher was painted up like a dragon and just ripped through the brick walls. The bricks just crumbled in its massive jaws. It was awesome.
The Muncher's opponent was just a battering ram that was set on a couple of A frames. It was just a really heavy gas pipe with a reinforced head and filled with lots of weight. The ram team only made it so the length of the cable holding the ram could be adjusted, otherwise it was just a hanging hulk of heavy metal.
The competition was to knock down three progressively stronger brick walls: 1 brick thick, 2 bricks thick, and 4 bricks thick.
In the first part of the race the muncher went straight through the single tiered wall. The bricks were pulverized by the muncher's mighty jaws. The second wall didn't pose much of a challenge either.
The battering ram took a little more time. It took something like three or four carefully placed hits to knock down the first wall. The second took a bit more time.
Meanwhile the muncher was chewing up bricks and knocking the loose ones aside with its big head. The motor was rumbling to feed the hydraulic pump. It was just a mean brick munching machine.
At the third wall, the muncher reached a bigger challenge. The wall was too thick to just munch away. The jaws of The Muncher could only pull a few bricks at a time. As the Muncher took on the thick wall the hydraulic pump stressed so much that its weak points, the hose connections, gave way and the muncher turned into a fountain of gushing red hydraulic fluid.
Meanwhile the battering ram team refined their technique. They made steady progress through the second wall, then moved on to the third. By the time they started on the third wall the ram team knew how to take it out in an efficient and effective way.
The muncher team resorted to swinging the muncher head on the crane swivel into an ineffective wrecking ball.
The ram team won.
This is the trend of the Junkyard Wars. The team with the most simple designs fared much better than the elaborate designs. Each layer of complexity for the junkyard machines introduced another opportunity for a breakdown.
In software, and software development, the principle remains the same. Less is more. Complexity in software is like moving parts in machines. The more complex something is, the more opportunities for it to fail. There's a measurement of complexity in software called Cyclomatic Complexity. Simply put, it measures the number of test cases it would take to test all paths within a unit of software. If one case can cover an entire method, that's very simple. The more cases it takes to cover the method, the more complex it is. For a class, people say that an index of 10 or less is ideal, sometimes classes have indexes of over 100, over 500. Those are the classes that are going to give you your problems.
One class that gave me fits was a 10000 line java class that I inherited on a job, I'll call this class SOSOM. I owned SOSOM for a year. SOSOM kept me busy and gave me lots of experience debugging complex problems. It also kept me away from keeping up with the industry.
SOSOM had one method that was over 2000 lines long. That 2000 line long method was the most frequently invoked method in SOSOM. SOSOM was also the most frequently invoked class within the largest Java enterprise application at the time.
SOSOM was critical to this enterprise application which many companies relied on. If the application failed, production lines stopped and money was lost. If SOSOM failed, the application failed.
SOSOM didn't start out the monster it was. At one time it was just a complex implementation of a service. Over time, features and capabilities were added. SOSOM was never refactored, features and specialized cases were added by different people and the complexity grew.
I don't work there anymore, maintaining that beast took too much out of me. The class itself was a big effort. The other element of complexity was the version tree. SOSOM is housed in a clearcase code repository. The number of versions for SOSOM was around 400 when I left.
There were three major versions of the product for which I was responsible. There were also about 20 point release versions that I also needed to watch. At any one of those points I could be tasked with finding out why a customer's system was failing.
SOSOM is The Muncher on steroids. I would have preferred a battering ram.
The irony is that SOSOM's purpose is pretty simple. It could have been a battering ram. Even with the extra features it could have been a simple implementation.
When I design things now I look to build battering rams. Simplicity is a gift and unnecessary complexity is a curse.