June 08, 2009
Older: What If A Key Value Store Mated With A Relational Database System?
Newer: JSONQuerying Your Rails Responses
What Is The Simplest Thing That Could Possibly Work?
I am always amazed when I read an article from 2004 and find interesting goodies. I’m probably late to the game on a lot of these articles, as I didn’t really dive into programming as a career until 2005, but I just read The Simplest Thing that Could Possibly Work, a conversation with Ward Cunningham by Bill Venners. The article was published on January 19, 2004, but it is truly timeless.
The Shortest Path
Simplicity is the shortest path to a solution.
“Shortest” doesn’t necessarily refer to lines of code or number of characters, but I see it more as the path that requires the least amount of complexity. As he mentions in the article, if someone releases a 20 page proof to a math problem and then later on, someone releases a 10 page proof for the same problem, the 10 page proof is not necessarily more simple.
The 10 page proof could use some form of mathematics that is not widely used in the community and takes some time to comprehend. This means the 10 page version could be less simple as it requires learning to understand, whereas the 20 page uses generally understood concepts.
I think this is a balance that we always fight with as programmers. What is simple? I can usually say simple or not simple when I look at code, but it is hard to define the rules for simplicity.
Work Today Makes You Better Tomorrow
The effort you expend today to understand the code will make you a more powerful programmer tomorrow.
This is one of the concepts that has made the biggest different in my programming knowledge over the past few years. The first time that I really did this was when I wrote about class and instance variables a few years back. Ever since then, when I come across something that I don’t understand, that I feel I should, I spend the time to understand it. I have grown immensely because of this and would recommend that you do the same if you aren’t already.
Narrow What You Think About
We had been thinking about too much at once, trying to achieve too complicated a goal, trying to code it too well.
This is something that I have been practicing a lot lately. You know how sometimes you just feel overwhelmed and don’t want to start a feature or project? What I’ve found is that when I feel this way it is because I’m trying to think about too much at once.
Ward encourages over and over in the article, think about what is the most simple possible thing that could work. Notice he did not say what is the simplest thing that would work, but rather what could work.
This is something that I’ve noticed recently while pairing with Brandon Keepers. Both of us almost apologize for some of the code we first implement, as we are afraid the other will think that is all we are capable of. What is funny, is that we both realize that you have to start with something and thus never judge. It is far easier to incrementally work towards a brilliant solution than to think it in your head and instantly code it.
Start with a test. Make the test pass. Rinse and repeat. Small, tested changes that solve only the immediate problem at hand always end up with a more simple solution than trying to do it all in one fell swoop. I’ve also found I’m more productive this way as I have less moments of wondering what to do next. The failing test tells me.
Anyway, I thought the article was interesting enough that I would post some of the highlights here and encourage you all to read it. If you know of some oldie, but goodie articles, link them up in the comments below.
9 Comments
Jun 08, 2009
I hadn’t read this before, thanks for sharing.
I really love the way the articles differentiates problems and difficulties:
Jun 08, 2009
@Michael I thought that was an interesting comparison as well. Glad you liked it.
Jun 08, 2009
John – So very, very well written. You have helped me out of a dilemma I was having over the best possible way to code something. I see now that instead of wasting time trying to do it perfectly, I should just go with what works NOW, and iterate up to something better. Thank you!
Jun 09, 2009
Thank you sooooooooo much for sharing this article.
good work man, keep posting!
Jun 10, 2009
I can’t count the number of projects I’ve started, got way ahead of myself in terms of features or perceived problems, and promptly given up on.
It’s interesting that you recommend using tests to combat that way of thinking. I’m going to have to force myself to learn to use testing first in my projects from now on. For some reason I’m having a really tough time wrapping my head around writing tests before writing any code. Maybe its time to finally getting around to buying the PeepCode Rspec video.
Jun 10, 2009
@Scott – Testing first is hard until you have a pretty good grasp of testing and what tests you need for things. I actually started by writing tests after I wrote code and verified that it was working externally. This helped me learn testing, but didn’t leave me frustrated and unsure whether my test or the code was the problem.
Not saying I recommend this, but it helped me. Also, I’d start with test/unit before RSpec. I think it is important to understand test/unit and see if it meets your needs. If it doesn’t, you can always switch.
Jun 11, 2009
@John – Cool! Thanks for pointing me in the right direction. I have a really bad habit of choosing the hardest possible thing to learn basic concepts with. Back in middle school I tried teaching myself how to program by starting a MUD before even knowing about “hello world”.
Jun 14, 2009
This article is only 3 years old, but I think it can already be called a classic.
Execution in the Kingdom of Nouns
http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html
Jun 28, 2009
I learned much from this article. This is not just for coding, but also for our daily life. Live in a simple way, don’t be lost in complex.
Thank you for the cool article.
Sorry, comments are closed for this article to ease the burden of pruning spam.