when things don’t work
Being part of the software industry for over fifteen years now, I understand that expecting your favourite software/hardware to be available 100% of the time is nothing short of wanting to win the jackpot each time you buy a lottery ticket.
Software or hardware is bound to fail; when it does, people/companies responsible for maintaining the software/hardware fix it as soon as possible. Some do it faster than others, but very few write a postmortem report. I wish more companies wrote postmortem reports.
I love reading postmortem reports of software that I use frequently. Knowing what went wrong when you were expecting things to work gives your users an insight into why the software/hardware failed. Companies often depend on external services; sometimes, bugs are outside the company’s control.
Writing postmortem reports is also a practice I want to promote with teams/companies I work with. Most bug reports from internal users get an “it’s fixed, please try now” reply. For the internal user, this is often enough. Still, for the internal IT team, it is good to write a detailed postmortem report so that everyone learns about what went wrong and what needs to be considered as they continue to build and maintain the software.