# Need Robust Software? Make It Fragile

Source: https://www.yegor256.com/2015/08/25/fail-fast.html

In any software project, the goal is to create something stable. We don't want it
to break in front of a user. We also don't want our website to show an
"internal application error" instead of a web page. We want our software
to work, not fail. That's a perfectly valid and logical desire,
but in order to achieve that, we have to make our software as fragile
as possible. This may sound counter-intuitive, but that's the way it is.
The more _fragile_ your app is in development, the more _robust_ it is
in production.


{% jb_picture_body %}

By fragile, I'm referring to the [Fail Fast](https://martinfowler.com/ieeeSoftware/failFast.pdf)
philosophy, which is the opposite of
Fail Safe. I believe you know the difference, but let me remind you anyway,
by example. This is Fail Safe:

```java
public int size(File file) {
  if (!file.exists()) {
    return 0;
  }
  return file.length();
}
```

{% youtube QMcDa2eyRBY %}

This method is supposed to calculate and return a file size. It first checks
whether the file exists. If it doesn't exist, the method returns zero. Indeed,
the file is absent, so there is no size. We could complain that the file is
absent, but what for? Why make noise? Let's keep it quiet and return zero.
We don't fail because we're trying to keep the app running. This is called Fail Safe.

To the contrary, this is how Fail Fast looks:

```java
public int size(File file) {
  if (!file.exists()) {
    throw new IllegalArgumentException(
      "There is no such file; I can't get its length."
    );
  }
  return file.length();
}
```

We can't find a file? We don't hide this fact. We make this situation
public and visible. We scream and cry. We
[throw]({% pst 2015/dec/2015-12-01-rethrow-exceptions %}) an exception. We _want_ the
app to crash, break, and fail, because someone gave us a file that doesn't
exist. We complain and protest. This is called Fail Fast.

{% quote Fail Safe approach conceals problems and makes code less maintainable, and that's why it's difficult to stabilize %}

Which philosophy, if we follow it everywhere, will make our software
robust and failure-resilient? Only the second one---the Fail Fast.

Why? Because the quicker and easier the failure is, the faster it will
be fixed. And the fix will be simpler and also more visible. Fail Fast
is a much better approach for maintainability. The code becomes cleaner.
It is much easier to track a failure. All methods are ready to break and throw
an exception on even the tiniest problem.

{% youtube nCGBgI1MNwE %}

In this example, if the method returns zero, it's not obvious
whether the file exists and its size is actually zero or if its name is wrong
and it is just not found. The Fail Safe approach _conceals_ problems and makes
code less maintainable, and that's why it's difficult to stabilize.

In the beginning, during production, we will have many crashes and errors. But
all of them will be visible and easy to understand. We will fix them and
cover them with unit tests. Each fix will make our software more _stable_
and better covered by tests.

Software designed with the Fail Safe approach in mind will look more stable
at the beginning, but it will degrade quickly and inevitably turn into
an unmaintainable mess.

Software designed with the Fail Fast approach in mind will crash frequently
at the beginning but will improve its stability with every fix and eventually
become very stable and robust.

That's why fragility is the key success factor for robustness.