Designed to Fail

“Success is not final, failure is not fatal: it is the courage to continue that counts.” — Winston Churchill

One of the most common phrases we hear and use within the software development community is “No program survives contact with the user.” Brief research shows that this is an rephrasing of a similar statement attributed to Field Marshall Helmuth Karl Bernhard Graf von Moltke, in which he stated “No battle plan ever survives contact with the enemy.”

While we certainly prefer not to view our users as the enemy, it is often the case that releasing software, art, or other resources to broader use can reveal flaws inherent to the project itself. In software we call these “bugs”, or if we’re feeling kind perhaps “emergent features.” In art and architecture, they’re often instead called “flaws,” or “imperfections.”

In any case, and by any terminology, failure states will occur. The key is to design both for success, and for failure.

Making Exceptions the Rule

In software development, an “exception” is an unanticipated error state in which the program hit a condition that cannot be fulfilled within its constraints. There are many causes for exceptions. In an ideal case, these will truly come from unanticipated conditions. Perhaps a file we were relying on has gone missing. Perhaps a remote server is no longer responding, or the database has shut off unexpectedly. It’s even possible that, despite our best efforts, a user has found a way to get the program into a state we didn’t plan for which it cannot handle on its own.

When we’re designing a building, a car, a rocket, or a website, it’s very easy to focus on how things should look when everything is working properly. This is the state we’re most concerned about, because we want this to be the state that the most people will see and interact with. As an artist, it is very easy to get focused on all the ways you want something to work without delving further into all the ways it should behave when it doesn’t work.

However, it is naïve to operate on the assumption that exceptions will not occur, or even that they will not be reasonably common. Treat exceptions as the norm. Assume that something can go wrong in any case and condition where it is possible to do so. Write code that allows the software to degrade gracefully. Give the building redundant supports so that a structural failure of one does not bring it down.

Failure By Design

If we operate on the assumption that our project will reach a failure state, we quickly identify that there must be some way to allow the project to continue as best it can while informing the relevant parties that a failure occurred. Total shutdown should be a final resort, not the first line of defense.

Consider Amazon as an example. This is a very complicated eCommerce site, and one of the strongest digital marketplaces in the world. They operate with millions of users, some as strict consumers and others as businesses, pushing transactions of many kinds in great volume throughout the day. The extreme majority of transactions will have no issues. However, in a complex system there are multiple points of failure.

It is possible that they will get enough traffic or orders to shut down their orders database. Even though that database is down, they do their best to never prevent the user from interacting with the site as much as possible. So, even when orders are offline a user may be able to go through the store, read reviews, explore products, search, and add items to their cart or wishlist. It is only when the user reaches the failure point that they are stopped, and when that occurs the user is notified that their desired interaction cannot be completed, but that they can continue to interact with other portions of the site while the system administrators address the issue.

In architecture, this can include stress fracture planning. When you look at a sidewalk or driveway, there are lines through the cement called “contraction joints”. They aren’t structurally necessary and they aren’t particularly appealing visually. In an ideal world and ideal design, they probably wouldn’t be there, so why do those lines exist? They exist for failure, for that undesired state. Due to natural processes, the land under and around a driveway or sidewalk will shift over time, adding stress to the cement. The contraction joints are intentional, structured weaknesses designed to be a controlled point of failure. By having them, the majority of fractures will occur along and down those lines, in relatively straight lines that can be easily patched and filled.

Redefining Success

In many cases, success can be defined as “working exactly as intended.” An application is successful if the user can do everything they’re supposed to do, and if it looks and acts the way it is intended to.

Such a definition of success is insufficient, though, because it only tells half the story. Success does not exist in a vacuum, and is not an absolute state. If everything is working properly, we’re certainly doing well, but we haven’t reached success just yet.

Success needs to be a broader term. Rather than considering success to be everything working as intended, we need to redefine it. Success is not the absolute inability to fail, but the ability to continue when failure occurs. Only the simplest projects can even be presumed to exist in a state where no error is possible, and even then it is still naïve to assume none could occur. When there is no possibility of existence without failure, we must consider success to mean the ability to fail in a controlled fashion and get back into a functional state to continue operating.

Making Better Mistakes

“Let’s make better mistakes tomorrow.” — Alex King

For over 4 years, I’ve worked at Crowd Favorite. When I began working here, the company was solely-owned by Alex King. Though he is no longer with us, he serves as a role-model and an inspiration for much of my approach to my career, and I would feel remiss not expressing my thoughts on how he has influenced me.

About Alex

Alex was one of the best developers I’ve had the privilege to work with. He worked through the .com bubble in Silicon Valley, invented the share icon, helped develop the core blogging framework that would become WordPress, and built a reputation for excellence and pride both in his own work and in the work that was done within his company.

As a developer, and as an employer, Alex had high expectations on himself and his employees. He pushed everyone he worked with to do their best, almost always beyond their comfort and sometimes even beyond their limits. Very little that was less than perfect was good enough. More than once, I witnessed products we branded get delayed due to perfection paralysis. If it didn’t meet his vision, it wasn’t yet ready for it to be seen by others. Alex built his reputation on his excellence, on his demands, and that he would go to the same lengths for a client project that he would go to for his own. Nothing less than the best was good enough.

Despite that demand for excellence, Alex was more understanding than it may sound. He pushed for perfection, and he demanded excellence, but recognized that you cannot have such success without failures. He knew that failure can be a success, because we can learn from it, and accepted that those he hired may do things in ways that didn’t work out. This was especially true as he pushed us to expand our horizons, to go beyond the way things are done into the way things could be done better. Sometimes, we would iterate for significant time trying to figure something out, and still settle on doing it the way it’s been done before. This was valuable time, because we explored other options, we tested our assumptions, and we grew in our knowledge of our applications and our limitations.

Unfortunately, in 2013 Alex was diagnosed with cancer, and had to step away from the business, and from development as a whole. He fought a long battle, and ultimately passed away in September of this year. He left behind a wonderful family, and the remembrances and his ongoing influence among those who were fortunate enough to have worked with him.

“Let’s Make Better Mistakes Tomorrow.”

One of Alex’s most memorable sayings was “Let’s make better mistakes tomorrow,” and I’ve tried to keep that in mind as a I grow and develop professionally, and as a person. As demanding as Alex ever was on me, I have always had the tendency to be equally or more demanding on myself. I’ve had projects that intimidated me, where I felt myself failing before I began, and in those cases I then had to fight both my own fears and the demanded growth simultaneously. That fear only added a greater chance to fail without motivation to grow. Accepting the possibility of that failure, moving past that fear, was where I was able to grow.

I’m still not perfect, of course, nor do I want to be. Perfection has no room for growth, and represents stagnation. I don’t want to be perfect because I don’t want to stop growing, learning, adapting, and experiencing new things. Sometimes it can be difficult to push past that fear, but even that is another opportunity for growth and there is success just in getting past that point.

It can be a very big challenge to accept that things won’t always go well, or that we don’t start out fully competent at everything we do to the same level of excellence as others who have done it for years. It can be intimidating to put ourselves out there to be judged by those we consider superior within a field. It can be difficult to forgive ourselves the easy mistakes, and the missed opportunities, that come up as we develop. We can’t expect to be perfect. We can’t expect to ever know everything.

All we can demand of ourselves, all we can really push for, is to do our best and never stop trying. Let’s not stay in our comfort zone. Let’s get out there, learn, try new things, and make better mistakes tomorrow.

The Paralysis of Perfection

“Perfection is not attainable, but if we chase perfection we can catch excellence.” — Vince Lombardi

For over two years now I’ve owned the devbyday.com domain. For over two years it has sat dormant. There is so much potential, and so much available that I want to achieve, that I wanted to hold off until I got everything just right before revealing it to the world at large. And therein lies the problem. In seeking perfection, I allowed myself to slip into the comfortable view that having nothing is better than having something imperfect. That is the paralysis of perfection.

It’s easy, as a developer, designer, or client, to get into such a mindset. We want the world to see something in a very specific way, and have such expectations, that we would rather reveal only when it’s ready. I find that, too often, this leads to endless iteration, particularly when perfection is not something with clearly defined expectation and goals. Over the past two years I’ve gone through several cycles of evaluating designs, and implementing my own, but never finding the one that truly stood out to me as the perfect model of my design, and my unclear vision.

The Cost of Perfection

At a Mexican restaurant near my office, they have a saying painted on the wall: “Perfeccion tiene su precio.” (“Perfection has a price” in English). This is very true. Apart from the obvious financial components of this price, there are more intangible costs that we pay. On top of the simple costs of hours spent working on a design for this site and researching options, on top of the costs incurred by hosting and owning a domain but not providing any content, there was a price in knowledge.

Until now, I’ve not written anything on this site. However, that does not mean nothing has happened in the last two years. That does not mean there is nothing I’ve learned in the past two years. On the contrary, I’ve grown significantly, in both professional and personal capacities. I’ve had great ideas for posts and articles to write on my experiences. Those ideas are all lost now, casualties to my search for an ideal, and a more substantial cost to that quest. Perfection has cost me money, and cost me knowledge. The worst part is that paying the price for perfection does not mean perfection can be purchased. Perfection may never be achieved, but striving for it without practical concerns will ensure significant ongoing costs.

Perfection as an Ideal

Striving for perfection has a cost, and perfection may not ever be achieved, but that does not mean we should not try anyway. By reaching for the stars, we learn what our limits are. If we give ourselves measures that are impossible to match, we have a lasting gauge for our continued growth and personal improvement.

In that sense, desiring perfection is a laudable behavior. It comes down to the difference between recognizing when that perfection is being used as a measure for growth, and when it is being used instead to push us down and hold us back. For too long, perfection has become my expectation instead of my standard of measurement when it comes to this site, its contents, and its look and feel.

The price of perfection, as an expectation, has gotten too high, and it’s time to start the journey, and share that journey as it progresses, rather than only being willing to provide the results.