Engineering Blog

I love simple things. I always have. Perhaps that’s why I love programming; when it’s done right, it can be stupidly simple. I love that feeling of something just working without much thought or effort. It doesn’t happen often, but when it does it’s exhilarating. So, how does one make coding stupidly simple?

Duplication
Duplication is anti-simplicity; duplicated code, no matter how simple, could always be simpler (just remove the duplication ).

Delete Production Code
I absolutely love deleting code.  My goal on most commits (and work-days) is to have more lines deleted than added.  Less code usually means more simplicity for the system as a whole and I honestly feel like I’ve accomplished more when I delete/refactor old code than when I write new code.  Eliminating duplication is an easy way to delete code.

Add Test Code
In my experience, adding test code almost always forces you to simplify the production code that you are testing so that it’s easier to test.  Adding test code and deleting production code is like a double stuffed Oreo; it’s twice as awesome as a normal Oreo but probably four times the calories (note that I don’t actually eat cookies or anything containing sugar but it’s a metaphor).  I don’t have any statistics on this but I’d argue that code is four times healthier when it’s been double stuffed and I’m pretty sure that it’s at least twice as awesome .

Simple tests lead to simple code.  In my opinion, the hottest unit tests contain just three lines of code:
1.  Setup: setup whatever condition the test should be testing
2.  Action: call the method that you are testing
3.  Assertion: assert what you’d like to happen actually did happen

If you can write a test that has only three lines it seems really likely that the production code/method that is being tested is probably pretty simple.  If you can’t do it in three lines, write the most concise test you can and then think about what refactoring you can do in order to reduce the number of lines in the test.

Move Production Code
In a lot of cases, writing good tests will force you to move some of the code being tested into new classes.  This is a great side effect of test-writing and results in a simpler system.  These commits may contain slightly more lines added than deleted but it’s worth it for the added simplicity .

Readability
I’ve been talking a lot about deleting lines of code.  Sure, deleting is a great way to improve simplicity, but if readability is compromised than you’ve taken one step forward and two steps backwards.  I could probably get the entire Rally application into less than 10 lines of code; they’d be extremely long lines of code but what a commit that’d be: 500,000ish lines deleted, 10 lines added! WOW, that’d be awesome!  That’d probably be more than two steps backwards though, and I would probably receive the hardest nut-punching of my life from the rest of the developers .  My point is: simplicity and readability need to go hand-in-hand; neither should be compromised in favor of the other.

You’ve probably heard of the KISS (Keep It Simple Stupid) principle, but perhaps software developers should follow the “other” KISS principle: Keep It Stupid Simple… or depending on the state of your codebase: MISS (Make It Stupid Simple) .  What does simplicity mean to you?