Fail Fast Principle

There are 3 keys ways a developer usually approaches error handling in code.

  • Ignore
  • Fail Safe
  • Fail Fast

We have, at different point of writing code, used all three approaches. There are times when have good reasons to ignore a particular exception scenario, while at other times, we are opt for Fail Safe approach.

Fail Safe approach never hides the exception, but rather, delays it until it is safe to raise it. This is a reasonable approach, considering we are now swallowing an exception. But there is a huge problem with this approach. Most often than not, the Fail Safe approach makes the application to fail slowly, resulting in the system to continue working smoothly when the exception occurs and then fail later on. This, as a developer, inevitably leads you to spending hours debugging your code to trace a bug. What would have been a better approach ?

Fail Fast Principle

Fail Fast Principle that has its heart in Defensive Programming, encourage developers to fail fast and visibly when an exception occurs. The biggest benefit of this approach is a faster feedback loop. In early days of adhering to this principle, you might end with a lot frustrating moments as you might think your have build a fragile software, but remember, it is always better to fix the bugs upfront, than to have the customer face them. The Fast Fail Principle does exactly that for you and aids you in building a robust application.

That doesn’t mean that you should completely ignore the first two approaches. This is the guidelines I keep for myself.

  • Use Ignore, only when having really specific reasons.
  • Use Fast Safe, when it is a critical piece of code, and Failing Safe is a better approach
  • Any other times, Use Fail Fast.

 

StarFish Retrospective

“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”

– 12th Principle, Agile Manifesto

It doesn’t need any explanation why Retrospectives are important in any scrum team. Question is, how can we make Retrospective Sessions more effective.

I was in conversation with a friend recently and one of the things he said he is running into trouble with is that the team members attempt to blame each other rather than getting to root of issues during retrospective.

To start with, key lies in making it more transparent. That doesn’t mean you need to document and publish it to anyone outside the team to view it. That is effectively an anti-pattern that plagues the success of retrospective. Unless the team members believes that what happens during the retrospective lies within the team, they wouldn’t be open with their opinions. This is the same reason why Line-Managers should be kept away from such meetings.

Care should also be taken to ensure the meeting doesn’t end up as a blame game, which is why the role of Scrum Master becomes critical, in the way he facilitates the meeting. The idea should be generate positive energy and responsibility, rather than a blame game that ends up depressing and energy draining.

Sprint Retrospective

Sprint Retrospective’s are usually revolved around 3 key questions

  • What went well ?
  • What did not go well ?
  • What can be improved ?

StarFish Retrospective

If the Scrum Master feels the questions are too broader for team to answer, he could employ exercises like the StarFish in the retrospective. The Starfish focuses on 5 Questions, instead of 3.

  • Stop Doing : Focus on things which are not doing any benefits for the team, and rather is getting on the way
  • Start Doing : Focus on new things which can add value to team
  • Continue Doing : Recognize things which is working well, and team should continue doing.
  • Do more often : Recognize things which is working well for team and could do team more good if done more frequently
  • Reduce Doing : Recognize things which is working well, but could reduce the frequency a bit.

The key however lies on finding the root cause, for example for things that you have chosen to stop doing completely. The team need to understand why it is not working. For this the Scrum Master could employ methods like the 5 Whys.

5 Why’s

5 Why’s is a root cause analysis technique that focuses on getting to the root of any problem by repeatedly asking “Why”. Each answer would form the basis of next question. You could read more on the 5 Whys in Wikipedia.