Complexity and endless bugs

We humans are complex creatures, but our code does not have to be.

Code usually starts out as specifications. The KISS principal should apply here first.

Can a developer read the specs and understand at first reading exactly what they are meant to do? I have worked with some specs that were so complex and convoluted it took three readings just to understand enough to start asking questions. If the spec is hard to follow, the development is likely not going to be pretty.

Development - does it follow the stream of consciousness technique (spaghetti code) or is it clearly structured and easy to follow even by a non-developer? Since in my specialty - Dynamics NAV - we are developing business software, a business analyst should be able to read it and follow the logic.

I have seen two extremes - one side of the ditch is the never ending function - for NAV developers Codeunit 80 which at its peak went over 1,200 lines before ISVs added their additional code to it. It is still enormous, and violates the creators' mandate of no function of over 20 lines! The other side of the ditch - and also really hard to follow - is the endless layers of function performs where you have to go ten levels deep to get to the actual code. If a developer is lucky, there is only code at the bottom layer. In some cases there is code at every level. (Inventory Profile Offsetting for example - I guess this name may have made sense to someone, but I would rather stay away from whatever he/she was smoking at the time.)

What is usually the end result of over complexity? Bugs, and lots of them.

I have found that when there are many bugs, you usually end up with two other problems. First, the more bugs there are, the more likely your fixes will create new bugs - with diminishing returns - if you have ten bugs, you are more likely to fix them all; hundred bugs will take a few cycles of fixing new bugs - thousand bugs or more, you face the possibility of creating more bugs than you are fixing.

The second problem with many bugs - aided by complexity - is you will not find most of them in testing - they will show up continually in the reports of your frustrated users.

The current build of Windows 10 is 14393.693. What was wrong with the previous 14,392 builds? And what are all the sub builds? Have there been over 14,000,000 builds of Windows? Plus we get fixes every week as people find new ways to break Windows or cause us harm.

(We will keep very quiet about the current build of NAV.)

Conclusion - keep the design simple - if you cannot explain it easily, then go back and refine until it is. Keep the coding simple - if a non-developer cannot follow it, then restructure it and simplify it.