As I was updating my resume, I realized that I’ve been writing software either as my full-time job, or for a significant part of my day for 20 years now. I recently ran across a wonderful Landon Noss writes in Medium about what he’s learned after writing software for 12 years. It’s a long read, but worth it.
I suppose that two decades affords me some perspective, so I figured I would take a look back and see if there are any lessons I’ve learned over the years. This is the first in a four-part series.
Build the simplest thing that could possbly work
Prefer the simple to the high-falutin’ - Walt Whitman
Out of all of the projects that I’ve done in my career, only one of them was a dismal failure. I had just graduated college and started a job at Quark. They brought in a teacher to teach a class in Object Oriented Design, and I ate it up.
Soon thereafter, my first client ever, the owner of a chain of clubs in Colorado and Texas wanted some updates to the desktop Windows application I created for them. Mainly they wanted some minor UI updates to make it easier for them to enter data.
I figured that was a great opportunity to put my new Object-oriented skills to work. The original application I wrote as I was learning C++ was sloppy, and the way I wrote out the data felt like an ugly hack to me, so I rewrote the entire thing. It worked great on my machine, but it kept on losing data for my poor client, and I could never figure out why. They eventually got sick of testing my broken apps, so they just canned the whole project and stuck with the old version.
Thankfully I only lost a few months worth of weekends and a few thousand dollars. It was a small price to pay to learn that the only valid strategy for developing applications and evolving them is to work in small steps, and to keep things as simple as possible.
In the real world, people never know what they want ahead of time, but they have plenty of critique after the fact. The only way to mitigate this is by doing the simplest thing possible and iterating.
The ZeroMQ Guide (one of the best pieces of technical documentation anywhere) states this principle eloquently:
This process starts with a realization: we do not know what we have to make until after we start making it. Coming up with ideas or large-scale designs isn’t just wasteful, it’s a direct hindrance to designing the truly accurate solutions. The really juicy problems are hidden like far valleys, and any activity except active scouting creates a fog that hides those distant valleys. You need to keep mobile, pack light, and move fast.:
Stay tuned for Part II.