Failure is a bigger part of the design process, as you will usually encounter more failures than successes. Some ideas only encounter failure. I’ve talked about some of the experimental processes I take towards build software, so it seems appropriate to talk about some of the ways in which i’ve failed.

The most obvious mistake I make and encounter is bikeshedding, or pandering to trivial issues in lieu of progress. Bikeshedding is arguing over “num_adults” or “numAdults”, tabs or spaces, things that everyone has an opinion on, but the impact of the choice is minimal. As more people are involved, more time is wasted.

You can still pander to trivialities when you’re on your own. It’s all too easy to worry about the code you’re going to write, instead of just writing it. Sometimes you need to write code to understand the problem.

Unfortunately, writing code to understand the problem takes a lot of time, it can be quite frustrating to find our your approach doesn’t work and you have to start from scratch. I have thrown away countless prototypes, branches, and features as I find out the problem has outsmarted me.

I also fail by finding a more interesting version to solve, usually by solving an abstract or general version of the problem. Writing a web framework instead of a web site, writing a game engine instead of a game. Without research or experience, it’s hard to get these abstractions right — the most successful frameworks come from working products.

Frameworks are the most obvious symptom of over-generalizing, but it surfaces in other ways, under the guise of extensibility. Instead of writing the code I need, I write code that can be extended to solve other problems I don’t face at the moment. Extensible code is just code that it is easy to add features to, but not code that is easy to replace, change, or delete. You need to be able to remove features, as well as add them.

Instead of unnecessary abstraction, you can add unnecessary features to make the problem more interesting. I’m good at keeping bloat away from my professional work, but my hobby projects seem to suffer from it eternally. Being precise and clear about the problem will usually keep it in check, but you’ll need to add more constraints along the way.

Problems can become boring over time too. Starting an open source project is easy compared to keeping it alive. I am guilty of letting a few libraries rot, and many others never got beyond the first release. Along with abandoned libraries, there is mountains of code i’ve thought about and never written. Although my side projects are for my own entertainment, I shouldn’t be surprised if no-one else is interested, especially the ideas I haven’t written code for.

For every useful piece of software i’ve written, i’ve probably written a hundred failures.