Let's Make It More Complicated Than It Really Is Just To Prove How Clever We Are

LMIMCTIRIJTPHCWA - Let's Make It More Complicated Than It Really Is Just To Prove How Clever We Are

This is the exact opposite of the KISS principle which dates from the 1960s, and the Do the Simplest Thing That Could Possibly Work principle which dates from 2001 with the creation of the Agile/Extreme Programming movement. It may also be nown as KICK (Keep It Complex, Knucklehead).

It's followers believe that if a job really was that simple then anybody could do it and they would either be on a much lower salary or made redundant altogether. It is therefore in their own interests to create as many obstacles as possible and make the job as hard as possible so as to keep the number of practitioners artificially low and their salaries artificially high. They do this by creating ever more obscure and impractical rules and brand anyone who refuses to follow their rules as a heretic, an outsider, "not one of us", someone who should be ignored or even shunned.

This "let's-make-it-more-complicated" principle is prevalent in the world of Object Oriented Programming which, when it was started, was supposed to deliver on various promises, such as:

OOP is easier to learn for those new to computer programming than previous approaches, and its approach is often simpler to develop and to maintain, lending itself to more direct analysis, coding, and understanding of complex situations and procedures than other programming methods.

As a long-time practitioner of several of those previous paradigms - I programmed for 16+ years in COBOL and 10+ years in UNIFACE - I therefore expect, nay demand, that it live up to that promise. I only write enterprise applications which do nothing but put data into and get data out of a database (usually relational), and having written thousands of user transactions in dozens of different applications I have gradually refined my development process so that I can create new transactions with basic functionality very quickly indeed. What used to take weeks to achieve in COBOL I reduced to days in UNIFACE and then minutes in PHP, but for the OO purists this is still not good enough. A common argument I hear is this:

If you have one class per database table you are relegating each class to being no more than a simple transport mechanism for moving data between the database and the user interface. It is supposed to be more complicated than that.

Why should it be more complicated than that? I am following good programming practice by building structured, modular programs, I have implemented both the 3-Tier Architecture and the MVC design pattern which both promote reusable and maintainable software, so how can I be wrong?

The trouble with a lot of people nowadays is that they confuse "simple" as being the same as "not clever". Albert Einstein, a true genius of the 20th century, had this to say on the topic:

Everything should be made as simple as possible, but not simpler.
Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius - and a lot of courage - to move in the opposite direction.

Martin Fowler, the author of Patterns of Enterprise Application Architecture (PoEAA) wrote:

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Another person, whose name escapes me at the moment, wrote:

Any idiot can write code than only a genius can understand. A true genius can write code that any idiot can understand.
The mark of genius is to achieve complex things in a simple manner, not to achieve simple things in a complex manner.

Being a good programmer is not just a simple matter of following the rules or ideas laid down by other programmers in the mistaken belief that it will automatically make you as good as them, you have to be smart enough to know when a particular rule or idea is relevant to your current circumstances, and how to employ it to improve your code. Just because the GoF book contains 23 design patterns does not mean that it would be a good idea to put all 23 patterns in a single program. This is what Eric Gamma, one of its authors, had to say in How to Use Design Patterns when he heard of such programmers:

Trying to use all the patterns is a bad thing, because you will end up with synthetic designs - speculative designs that have flexibility that no one needs. These days software is too complex. We can't afford to speculate what else it should do. We need to really focus on what it needs.

This sentiment was echoed in the blog post When are design patterns the problem instead of the solution? in which T. E. D. wrote:

My problem with patterns is that there seems to be a central lie at the core of the concept: The idea that if you can somehow categorize the code experts write, then anyone can write expert code by just recognizing and mechanically applying the categories. That sounds great to managers, as expert software designers are relatively rare.

The problem is that it isn't true. You can't write expert-quality code with only "design patterns" any more than you can design your own professional fashion designer-quality clothing using only sewing patterns.

The world is full of far too many dogmatic programmers who believe that it is only by following every rule to the letter that acceptable software can be produced. By acceptable I mean acceptable to them. At the other end of the spectrum is the pragmatic programmer whose sole aim is to produce cost-effective software which is acceptable to the customer who will be paying the bill. This type of programmer will use his skill and experience to achieve his goals, and is wise enough to know when, where and how to apply a rule and when to ignore an inappropriate rule completely.

A problem I have with this "to the letter" approach is that virtually all of the principles of OOP are so badly defined that they are imprecise and open to large amounts of interpretation, and therefore mis-interpretation. It is therefore impossible to follow every interpretation of every rule, so no matter what you do there will always be someone somewhere saying "you are wrong!"

My software works, therefore it cannot be wrong. I can create new components at a faster rate and with more features than you can, therefore my methodology is better than yours. If I can do this by ignoring your over-complicated rules, then perhaps you should consider the fact that it is either those silly rules, or your silly interpretation of those silly rules, or even your silly implementation or your silly interpretation of those silly rules, which is wrong.

© Tony Marston
12th August 2015