Under-Engineering Is a Beautiful Start to Any Project

If you think about a lot of things in life, they’re over-engineered to the point of no return, aren’t they? Cars are a good example of going well past the realm of must-have. Have you ever lifted the hood on a 1974 BMW 2002? I did, and that squashed any thoughts I had of buying an older car. Where would I get parts? Where does the electrical system start and stop? Where the hell is everything?

Of course, my dad’s take on it was, “now this kind of car you can fix yourself! There isn’t anything under there we couldn’t make from scratch if we had to!” I was not moved to action; maintenance seemed all too simple and frankly it scared me.

Fast forward to this week; one of the fog lights on my wife’s car died. I couldn’t figure out how to remove the plastic casing to even see the bulb, let alone replace it. Looking in the manual, it clearly states that fog lights must be replaced by the dealer. I went online and the consensus is, let the dealer muck with changing fog lights.

I cannot even attempt to change my own fog lights. A simple car from 40 years ago scares me. I asked for this vicious circle, didn’t I?


In a world where we can’t change our own light bulbs, it is a scary thing to be prodded into simple action; go build something, go do that one thing you’ve always wanted to do. Do something remarkable; be someone remarkable. That is the challenge.

I’ve said many times, if I could start my own new business that made ten dollars, I could start a business that might do anything, yet I still haven’t made that $10.00.

Is it because my first answer is to engineer the hell out of something new?


There is a fundamental difference in using or buying something and evaluating its technical depth compared to building something oneself.

When I go to buy a car, I see things that are must haves, but they do not weigh on me in terms of “how do I build my AWD system and make it work with my existing RWD 2002”? AWD is more complex than RWD, but in an existing car, someone else has that figured out and it doesn’t impact my ability to use the car.

I didn’t build it and I don’t maintain it.

If I choose to use MVC in a recent project, I might be using it so that I don’t have to write my own framework. I just pick it up and start using it. It either suits my needs or it does not, but I don’t maintain it and I didn’t build it from scratch. Much like buying a car, it fills a need.

However, when we do go and build a new product, this same conclusion creeps in the back door. The big difference here is that you can’t go pick something off the shelf and bring your idea to life; you must build it yourself. You can’t pass off the original engineering and maintenance, you must do it yourself , all the while adding to and building onto your original idea that you should be doing anyway.

Ideas are like barnacles in that way, you can’t stop them from growing.

But the one place we do have control is at the start: Do we take on everything at once, or do we start simple and build out?


Starting a new project is hard because there are so many choices and so many competing ideas in today’s connectivity. I love photography, but sites like Flickr and Smugmug already exist. I couldn’t possibly match all the functionality they have, and so I go back to the drawing board looking for another panacea.

Along comes Instagram. They’re version 2.0 now, which brings a host of new features, but its still a very simple idea executed very well. Most people I know absolutely love it; I’m fairly certainly they love it entirely because of its simplicity.

I’m not calling the engineering in their application simple and I mean no offense, but the idea is simple: Take a picture, share a picture.

Maybe I could have started with a idea like this. Why didn’t I think of something so simple?


Test driven development declares that you should write the simplest code you possibly can in order to make a test pass. This heads off a lot of coding overkill and keeps developers focused on writing concise code that does exactly what the test says it should. I prefer to call them “specs” over “tests” in order to prevent confusion, but that’s just me.

The bottom line is that we’d all take slim and precise classes that get the job done over any other kind of code.

This is probably the best technical example I can think of where simple is the end goal of the entire engineering process.


So, for my next idea, I’m starting absurdly simple. I’m not going to try to match anyone feature for feature. In fact, I’m not going to even think of what anyone else is doing. That problem takes care of itself at some point in the future despite best intentions anyway. I’m just going to take an idea and think of something, anything mind-bogglingly simple, and think of where I might go, what I might do..

If I bought the 1974 2002, then I could change my own foglights. That might lead to installing a new alternator, which might lead to replacing the front wheel bearings. Soon afterwards, pistons might be rolling around on the garage floor.

But I have to start somewhere; better to start with light bulbs than engine rebuilding, no?

I like music, maybe I will start there. What software could I write that does something with a one song playlist?