Billion Dollar Mistakes

DRAFT

This page narrows down the problems to the few biggest ones. They make code very hard to maintain so they make coding a very time-consuming activity.

Unfortunately, they are all part of our usual coding practices. We don't even treat them as issues. We think that they are what we call programming. I'd like to point out that they shouldn't be.

Object-oriented programming

Problems

OOP results in very hard-to-read and hard-to-write code. It hides the business logic, which is the opposite of what the code should do.

It is the most expensive way of coding. Most of the coding time is spent solely on understanding and maintaining class hierarchies. This time is missing from working on the business requirements. A lot of time is wasted.

Using OOP is not necessary. (At least in most of the programming situations.) So the price/benefit ratio is extremely high.

After separating data and procedures we don't have classes. As a consequence most of the OOP rules we know become invalid.

Solutions

Quit OOP.

Separate data and procedures.

Use the Composite pattern.

Model the real-life domain entities with the data model and not with the procedural components.

High number of branching

Problems

Branchings increase the cyclomatic complexity of the program. It is measured only for single methods but not for the entire program. We have a blind spot for this problem.

We write ifs and other forms of branching everywhere in the code. We create class hierarchies and other patterns that are based on branching. We do it in an irresponsible way; we don't care how many branching we create.

The high number of branching is also a consequence of antipatterns, like passing and returning nulls or controlling the program flow with nulls. (Spaghetti code, Insider trading, Common code that is not common.)

Solutions

Separate use cases.

Separate use cases only once and as early as possible.

Automation

Problems

We write code that automates the program in runtime.

Frameworks, common code.

This is not the program we should write.

Everything that is known in coding time should be written in the code and explicitly called from use cases.

Solutions

Common code that is not common

Problems

This problem goes hand-in-hand with the branching problem and the automation.

Solutions

Separate everything.

Incorrect data processing

Problems

We never identify a program as a "data processing code".

We should write components with clearly defined input and output data structures.

A "backend" is a data processing code.

Solutions

I took the click-bait title from this speech: Null References: The Billion Dollar Mistake.