Are you over-engineering your code?

Over-engineering is when you make your code more flexible or sophisticated than it needs to be.

It is not uncommon for many architects and programmers to add unnecessary flexibility and complexity to their designs because they believe they know their system's future requirements.

The problem with attempting to predict the needs of tomorrow is that often these predictions do not materialise.

The result is a code base that is larger and more complicated than it needs to be and this contributes to a decline in team productivity.

How reliable is your system?

There is no point in building an unreliable system however building resiliency into your system and environment only reduces the potential for failure, it does not eliminate it.

With user driven systems this is not so much an issue. If the system fails, the user can check to see if the system has been updated and continue working.

With computer driven mass processing systems problems tend to be multiplied by the rate at which the system works. Therefore a timely resolution to a failure may be impossible.

It is therefore essential for computer driven systems to have a means of recovering from a failure in a timely manner.

Without the recovery processes your system may not be as reliable as you may think.

Why is idempotence so important?

Every enterprise system has some operations that need to occur only once.

Typically transactions are used to guarantee only once processing. Although transactions work well inside applications they don't work so well when connecting systems together.

Distributed transactions do guarantee only once processing given infinite time, however during this time resources are often locked and this may cause the applications to become unusable.

The use of transactions to guarantee only once processing between connected systems is therefore not practical, but building an unreliable system is senseless so we need an alternative.

Without transactions the best we can do is ensure a message will be delivered at least once. If we need to ensure only once processing, we need to make sure the target system won't duplicate the work if it receives duplicate messages.

In other words, we need the target system to be idempotent.