Fail fast and often

Fail fast and often

Being fail-tolerant is valued in organizations as in a changing world where requirements, technologies or even team members can change from one day to the next, having adaptative capacities is gold.

Wait, what are you talking about?

I am talking about having the ability to prioritize our work as developers. Everything has not the same importance and our resources are finite.

You have to know what is the aim of your organization. Are you working for a well-positioned big company that is looking the excellence in its products? Or are you working for a startup that is trying to create the product as fast as possible?

What resources are at your disposition?

In an ideal world there would be no difference, because good practices are mandatory, e.g.

  • Everything must be tested (unit and integration tests).
  • All code must be reviewed.
  • Documentation must be included with each feature.

But doing all of that consumes resources. It could be developer time, mindpower or even compute time. At the end, a resource is needed.

That is the main difference between programmer and engineer. Maybe they can do the same work, but the engineer knows how to optimize resources, and ensure the delivery of the release.

Do we have a solution if we have limited resources?

How about failing as soon as possible and fixing the failures? Maybe it is easier to fix an error than to make all the possible tasks to avoid having errors.

I know that it sounds counter-intuitive, but try to think about an organization with limited number of developers, and also with a limited cash-flow. Maybe, from the business point of view, it is better to provide features than to make a 100% infallible software.

Conclusion

There are no absolute truths in the world of the Software Engineering. Examine what are your restrictions (personel, time, skills, etc.) and act in consequence.