Complexity Is Bugs

Not long ago I said "Complexity hides bugs." I no longer think that's true.

If it were true, then when I was simplifying code while looking for a bug, I would expect there to be a point where the bug was visible in the newly simplified code. I haven't seen that happen.

What I have seen is that the code, now simplified, no longer contains the bug.

Therefore, I offer you this pithy one-liner for your enjoyment, derision, and dissection:

: Complexity is bugs.

-- WayneConrad

You're probably not seeing the bugs because you are mentally reverse engineering the code back to its requirements, where the bugs don't exist. If you did a more rigorously code-based translation, you'd be more likely to see them. By the way, that reverse engineering step might let in some bugs of its own. For example, when a feature is hiding in some complex code such that you didn't see it, and your new simplified version doesn't have it.

I think your earlier pronouncement was more accurate. The bed is not the bedbug, but to be certain, throw them both out.

--WaldenMathews

If bug is defined as code failing (dumping core, crashing, etc), then the title is correct. Bugs in requirements can produce code that is wonderfully simple, clean, clear, and robust, but wrong. --PeteHardie

This is very like the DoTheSimplestThingThatCouldPossiblyWork isn't it? --MatthewTheobalds

There must be a corollary to MooresLaw about the growth in complexity.

All the flavors of Unix, and the OperatingSystems from vendors such as Microsoft, Apple, and Cisco keep growing in both size and complexity. It gets to the point where you have to buy new hardware because the new OS requires more resources. This is why I find PlanNineFromBellLabs to be a refreshing leap in the opposite direction: Each time those guys (the InventorsOfUnix) fix something, it gets smaller and simpler. --ChrisGarrod

Maybe Metcalfe's Law: The number of edges in a network of nodes (n) is n(n − 1)/2, i.e. is proportional to n^2

-- John Tait

I would say that complexity and bugs come from the same root problem, lack of understanding. If you do not understand a problem or do not understand how to resolve it, your solution will likely be unfocused and complex. Also, if you do not understand, your solution will likely have bugs. This is merely a restatement of the concept of QualityIsFree. --WayneMack

But the real heart of programming is exactly discovering that understanding -- only as you build the solution do you begin to truly understand the problem. If we truly even understood the problem beforehand, programming would be an exercise in mechanical translation. (Implementing yet another hashtable, B-Tree, or XML parser using the same algorithms as another may have its pedantic beauty, but is very far from the true challenge of most programs that I find myself writing these days.) So I think DoTheSimplestThingThatCouldPossiblyWork is about arriving at the most fundamental understanding of a problem. The solution to that problem is almost a side-effect of the understanding. --AndrewGeweke

You could also say "complexity is a bug", referring to the complexity of a given solution that exceeds the essential complexity of the problem. The reasoning is that a "bug" is an instance of poor quality, translated concretely to someone's dissatisfaction. And excess complexity is a source of dissatisfaction to anyone seeking control over the quality of a solution. Accepting unnecessary complexity, therefore, is itself a "bug", an error in judgment, and one that leads to derivative "bugs" in the product.

--WaldenMathews

I like this idea. -- WayneConrad

. Buggy things fail, complex things can also fail. Complexity can lead to bugs which eventually leads to the failure. . [ feature + bugs ] --(wrapped-in)--> complexity . [ feature + bugs ] --(unwrap)--> feature (keep) + bugs (throw)

-- Prash

CategoryComplexity