Bad Software Advice: Three Interesting Links #4
Also: YABR: Yet Another Book Recommendation
Today’s theme, and perhaps the leitmotif of this newsletter, is failure. Learning from failure, not just failing. Here are four stories of failures or near-misses. There were supposed to be three, but there is an off-by-one bug somewhere1, so please deal with this as best you can.
Also this:
An interesting thing to think about if you need to stay awake is how failure patterns will evolve in the age of AI, where the “cover-up” might be from a technical agent and not a group of human beings. We have studied how human beings behave under pressure (badly most of the time, then later - very well), when caught (badly), or when put under the spotlight (badly). I don’t think we have studied how an AI told to accomplish a goal might over-optimize for that goal and then cover up what it broke to get there. Sweet dreams!
An Unsolicited Book Recommendation
Speaking of over-optimizing one goal at the expense of others, there exists a point in your career when you realize that the best coding in the world will no longer directly lead to success. You need to learn how to choose projects that have an impact and to communicate and persuade those around you that a particular effort should be approved. There aren’t a lot of books explaining how to do this for complex projects, and so many of us have to figure out how to do something better than building a PowerPoint presentation that explains a complex technical approach to executives. And this doesn’t always go that well.
The book Technology Strategy Patterns provides a better framework and tools to drill down when needed and step back when appropriate to create and explain a technical strategy. This is a guidebook for when you need approval for a complex refactor project from a dozen people within the various levels of leadership. Also, it has a perfect subtitle: Architecture as Strategy. It is an excellent read if any part of your job, no matter what your title is, involves figuring out the context in which you work, choosing what to work on versus how to do it, and especially if any part of your job involves explaining why something should be done to someone who might pay for it to be done but not be involved at any level later.
There are 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors. // Leon Bambrick
Here's another failure for your list:
http://sunnyday.mit.edu/papers/therac.pdf