Code Small FTW: Monday

TL;DR: My yearly performance review revealed that I have a tendency to over architect code. I write too much too early. Using the Pomodoro Technique, a few ground rules and a rigorous commitment to coding only what was needed, I created an iPhone app with a full stack backend in 20 hours over the course of 11 days. My wife and I are now using the app on a daily basis. All the code is open source and can be found here (server) and here (iPhone app).

Background

I work on a small development team for Didit, Inc. We are dedicated to an Agile methodology that suits our needs (mainly Kanban) and we have an introspective bent where we are always trying to improve our craft. We crunch lots of data in our work. Our technology stack includes Hadoop, Postgres, Mongo and Node.js as servers and Javascript, Cascalog and Java languages. We work a lot with the search engine APIs. The users we develop for are our internal Client Services team.

A few comments from my yearly performance review stuck with me:

…”I’d like to be a little more confident that Micah is always focused on simplicity.”…
and

…”On occasion, Micah can spend a little more time than necessary chasing down a dead end.”…

I tend to overreach when writing code. It’s not uncommon among software developers. Even having evangelized and lived Agile for many years now, my natural tendency is to “code for the future”.

Here’s a common scenario: We need a picker on a web app. We know there are four items in the drop down. We also know that in the near future, there will be other options. We take on hooking the picker to a model that in turn makes use of a service that hits the backend database to retrieve all the available options. What would happen if, in the first iteration of this app, we simply hardcoded that picker with the options we knew we needed right now? Sacrilege! The code will have to be entirely rewritten the first time another option is needed! But, we’d get this function into the hands of our users much more quickly.

After my review, I was really fired up. I wanted to take this feedback and produce a tangible result. I asked myself this question: What could I produce if I were to write the simplest, most focused code possible for a real world problem?

The Project

My wife and I have been tracking our daily expenditures for quite a while now. We started out with pen and paper, went to the Notes app on our iPhones and, ultimately, settled on simplenote because of it’s syncing ability. Our “finances” note had sections for checks, cash and debit card purchases. Typically, at the end of a day or two, I would take the simplenote data and enter it into clearcheckbook.

Simplenote is a great app, but it has been a little painful to use it for tracking our finances. Loading up the note, finding the proper section and editing the note is time consuming. There is a Clearcheckbook app, but it’s reliance on the network for practically every touch makes it cumbersome.

With the context of “the simplest thing that works” and my commitment to break my habit of over-architecting, I decide to take this on as an iPhone app project.

Hi. Micah, here. I’m cutting into the narrative here; breaking the “fourth wall”, if you will. I originally wrote this as one giant post. My colleagues at work gave me the feedback that it was too damn long (paraphrasing) to read in one sitting. Therefore, I am breaking it up into daily installments each day this week. This first installment continues through the ground rules I set for myself and a look at a day in the life of a part-time side project.

Ground Rules

I decided on the following ground rules:

Principles:

• The network can’t get in the way.
• It should be as fast as writing on a piece of paper.
• It should be usable with one hand.
• Truly embrace the “simplest thing that works”. If that meant hard coding in places, then so be it.
• The App only has to work for my wife and I. No other (future) audience would be taken into account.

Process:

• Adherence to pomodoros – 25 minutes of uninterrupted work followed by a break.
• Review each Pomodoro. Look for places where I did “too much” and correct it in the next one.

Technology:

• Titanium Appcelerator for App development because I was already familiar with it (See my Passable project).
• RESTful API using Node.js for the server side because I was already familiar with it.
• Everything server side would have full test coverage, written first, bdd style.
• App side testing would be done using console logging and eyeballs. Sacrilege, I know.
• Use Heroku and MongoHQ for hosting since it’s free.

Wow! I just realized that I have written this far without starting a Pomodoro. Old habits die hard. I am going to take a break – better yet, I am going to go to sleep and pick this up tomorrow – WITH Pomodoros.

OK. It’s the next day. I am well rested and I just started a Pomodoro.

My goal for the project: Have a usable App on our iPhones within 24 working hours from the start of the first Pomodoro. I didn’t know how much time I would have to devote to the project, so I didn’t put any restrictions on the number of days it would take.

The Work

I thought I would share with you a timeline that took me through the first few Pomodoro’s on the first day. I won’t go through this for the entirety of the project, I promise!

Day 1

So, day 1 was a mixed bag – some great pomodoro work, some unstructured, less productive dev time when I hit a snag and lots of other run-of-the-mill normal weekend day stuff.

I want to take a step back here. With my daughter’s Bat Mitzvah less than a week away, it may seem crazy that I decided to take on a project like this. For me, though, something like this was exactly what I needed. With all the chaos of planning a big life event like this, I found it relaxing to step away and exercise my brain for 25 minutes at a time.

Tomorrow’s installment: The Design and Testing the App