Errors are an inevitable part of building software. But while you can't eradicate them, you can definitely mitigate them. If you don't measure, track or resolve errors, you're ignoring a loss in revenue. It's time to pay attention to how much software errors are costing your company and take action, catching them early with methods like smarter testing and crash reporting. Using a few industry averages, you can put a number to the real cost of software errors in your company and start to plug cash leaks like wasted developer time and lost customers.

This is Part 2 of a two-part series on Blameless Postmortems. The previous article went into why blameless postmortems are so effective; this second part goes into detail on how to build your own postmortem process and kick it into overdrive. Read Part 1 here. So you've read our first installment and recognized the value of the blameless postmortem for efficiency, culture, and output. Now you're ready to get off the blame train and kickstart a blameless postmortem process of your own. Where to begin?

This is Part 1 of a two-part series on Blameless Postmortems. Today, we'll discuss why blameless postmortems are so important and their implications for your team; the second part will go into detail on how to set them up as a process and make them successful. Somebody wise may have once told you that how we handle adversity shows our character. Being able to acknowledge and admit mistakes is the first step towards learning - it's a key part of success both in personal relationships and in large companies.

Large-scale software projects don't care how many unit tests you put into your code. Or how sophisticated your CI/CD pipeline is. Or how robustly you run blue-green deployments to ease into newly-deployed code. These projects will inevitably find themselves subjected to your users, who will uncover bugs your team didn't catch and didn't even think to test for.