Reduce the code to the minimum

Reduce the code to the minimum but not less. This fundamental  principle of mechanical engineering fits also extremely well to software engineering and software resilience. Remove all unneeded wrapper, boiler plate code, indirections. 

1. Less code mean less bugs
2. Less code keeps your software side effect free
3. Less code means less hidden knowledge 
4. Less code - less dependencies
5. Less code means less code to read

But be careful. Be sure that your code is well-covered from tests. Every mature project came's into a phase where the software developer delete more lines than they are writing new.

Exception handling - resilience in small

On of the most discussed software development topics is the right exception handling. Exception handling is one of the basic building blocks of resilience and without any surprise the correct exception handling depends on your application.

But here some well working tips to keep exception handling easy:

1. Find out how important is this code place. If you compare it with a car, is it the breaker or is it the seat heating.
2. If your code is the "seat heating" category then:
1. Catch the exception
2. Log the exception as error.
3. Maybe count the errors as metric and put the metric on a dashboard.
3. If your code is in the "brake" category then
1. Maybe catch and log the exception with the context e.g. the related method parameter
2. Throw re-throw the exception and handle it on the presentation layer (front end)
4. If you can't clearly decide between the categories "seat heating" and "brake"
1. handle the exception like category "seat heating"
2. create an alert on the metric
5. If you have an fallback use the fallback and count the usage via log message or as metric

Rule: Never Deploy on Friday

 

Many developers know the unwritten rule: Never deploy on Friday. The reason for this rule is that nobody wants to repair a live system at the weekend.

If you live this rule, it's a very good indicator for three things they are wrong in your software development:

1. Your application is not well tested for resilience e.g. with Chaos Engineering tools.
2. Your deployment pipeline is not stable enough or you not trust them and your tests.
3. Your not familiar with roll-backs or you have no feature toggles.

One of the major goal is to trust your software and the test so that you feel comfortable to deploy on every Fridays.

One of my major project goes online on Friday afternoon, most developers was not in the office, with success.