2000 Bug Software House

Why
so many
BUGS?

The Rubik's cube analogy

The Rubik's cube seems to be silly to solve, but when you start to assemble the second face, you end up messing up the first face you had already solved. You allowed yourself too many options of movement, but you can't track the impact of these movements.

Most algorithms to solve the cube follow a basic constraint: if you rotate towards one direction, you have to rotate back to the opposite direction at some point. This simple constraint reduces the impact you can create, at the expense of extra movements.

Windows spends millions of dollars
to be just as stable as Linux.

Windows is highly customized to support antivirus and to run games. For instance, the so-called DirectX is nothing but a direct access to the hardware so the games can run smoothly. But this doesn't come without a cost. Before being launched, Microsoft employees millions of dollars to test and fix it. Many companies have the exact same challenge, which is called technical debt, the extra time the developer needs to ship a feature due overall instability.

On the other hand, Linux is an OpenSource software that is maintained by volunteers, so it can't afford the same quality assurance process. Instead, it relies on a simple design that limits itself. While Windows dominates the market for games and corporate computers, Linux thrives on servers and mobile because of its affordable dependability. Why don't SMB companies simplify their software just like OpenSource software?

The more points of failure
the greater the chance of failure

Here is an analogy with the natural world.

Chemistry solutions

It's tempting to change the very nature of the matter. This enables great customization to solve a great variety of problems. But, something created from scratch is not time-proven, and some of the decisions can hide unwanted consequences.

Physics solutions

If you limit yourself to not change the nature of the matter, you can build solutions that combine components that are already stable. These solutions can't fail because of the components themselves, only by the way they interact among them.

Biology solutions

Limiting yourself to not change both the matter nor the array will create something as stable as the natural selection itself. The only customization you have is the name of the species that may already solve your problem.

The more decision points you want to have,
the greater the chance you'll make a mistake,
and the more you'll have to trial and test.

Don't reinvent the wheel

A trede-off between Tailored, Standarized and Third-part

If you start to stock features one above another, you'll realize that the same bug repeat itself everywhere.

Then, you decide to abstract your code in components, so every bug happens only once. But, now you have to write documentation, respond Q&A, and give support with retrocompatibility for these custom-made abstractions.

Finally, you decide to just use the third-part components with limited customization, because they are cheap and stable.

Are you looking for a simple technology?

⇐ Why 70% SMB shortfall digitalization.

⇒ Learn the guidelines we use to build it.

Why so many BUGS?