"What I've Learned From Failure" Book Writeup

April 01, 2012


What’s the point?
Delivering software is as much about avoiding “failure modes” as it is about using best practices or the flavor-of-the-month process. By identifying common sources of failure, we can learn how to avoid them, fix them, or realize that a project has gone pear-shaped and get out while we still can.

How was it?
One of my new favorites; after finishing a project that was…less than successful in some areas, it was enlightening to read this book and be able to relate first hand.

One of my favorite sections detailed what stakeholders want when things starting going wrong: new processes and a way to measure compliance.

Often the responses are anti-patterns like working overtime (“Schedule slips are the fault of the estimator or the person implementing the task so we have to start working weekend to make up for our faults”) or generating mountains of reports and vanity metrics (“The app is crashing a lot, we need to see test coverage reports with every future release”).

For whatever reason, I felt as if the author had really been in the trenches on failed projects so even when I encountered material I had read/heard before, there was much more conviction and impact behind it.

Do not let the length fool you, it is short but dense with great material.

Who should read it?
Project managers and clients that want to avoid failure; frustrated engineers that don’t always understand the How and Why of dealing with clients


built with , Jekyll, and GitHub Pages — read the fine print