Nik Wakelin

I was recently helping out with a work in progress Software-as-a-Service app for the enterprise space. One of the developers and I were browsing through the code when I noticed a bunch of complex XML templates.

The app in question is clever, but pretty cut-and-dried from a technical perspective (most of the innovation is in the business model), so I was surprised to see so much complex code.

“What’s that for?”

“Oh, that’s just in case we want to integrate with [insert acronym-soup enterprise product with high-six-figure price tag here]. I’ve had a lot of experience with it and I think it would be useful”

This is a tough situation. The code is pretty good, and undoubtedly the experience will be incredibly valuable — in six months.

Programmers are force multipliers. We take the boring stuff and get a computer to do it so that other people are free to do the interesting bits. The value equation for a coder looks something like this:

value =
  (complexity of problem solved) *
  (number of times code is run)

So if you’re solving a bunch of super hard problems you only need to solve them for a few people to be valuable. Conversely, if you’re only saving someone five minutes you’d best be multiplying that by every single member of your organisation.

The tyranny of that equation is that if your code is never run, you might as well not have written it.

So how do you avoid the zeroes?

You can start by distrusting requirements. It doesn’t take long to write “generates Word Document output”. It takes a lot longer to actually make that work. Do you really need it right now, or can you wait till people are screaming for it?

Perhaps you don’t know what your users really want. We launched MinuteDock with a very simple reports screen, showing totals across the week and not much else. Our plans showed us adding advanced time logging features over the next few weeks, but we quickly had to about face as the requests for advanced reporting piled up.

Sometimes it’s tough to make the complex solution easier than what people are already doing. At 200 Square, we had a lot of people emailing us their photos of their house rather than using our fancy image uploader. So we added an “upload via email” function, where people could send their photos to a special address and have them automatically appear.

I was braced for an avalanche of emailed photos. I watched the stats, and in the first two weeks we had exactly zero uploads via email. My code wasn’t being run! In the end, it was easier to just reply to the last email our agents had sent than it was to log in, find the “Photo” section, copy the fancy email address and attach your photos. Plus, it’s much more straightforward to get advice about which photos should go where and the quality of your pictures when you can have a conversation at the same time. Lesson learned!

It’s also about finding the low-hanging-fruit - go grab the big multipliers first, because as your product & business grow so do the number of potential times for your code to be run. Sure, you could spend two weeks (~80 hours) coming up with a solution that will save the CEO 15 minutes per day of copy-and-paste. But, if she’s only copy-and-pasting once per day, it will take 320 days (10 months) for that code change to break even! If you can hold off till she’s doing it fifteen or twenty times per day (and most likely aiming a meaningful glare in your direction each time), then it takes just two or three weeks for that change to pay off.

In the end, the developer and I decided to hold off on the enterprise XML generation. Instead he moved on to focus on the most important feature of all — getting the product live so people could run his code!

Thanks to Michael Koziarski and Jared Armstrong for giving feedback on drafts of this post


Back when we were building one of my first startups, we started each realign/redesign (not quite major enough to earn “pivot”) with a codename.

We started small with “Strawberry”, and quickly advanced to “Pavlova”. I guess we hoped we’d “make it happen” before we ran out of suitably opulent strawberry-based-desserts.

Each time we were convinced that all our problems would be solved if we could only get the new design live, or swap in a shiny new charting library.

The “Silver Feature” is a common, and dangerous, antipattern.

Coders are especially susceptible. After all, if the only success-lever you have available to pull is labelled “feature”, then you’re liable to give it a go.

It’s dangerous to hang your hat on a single success. You expect the late nights and long weekends getting ready for that TechCrunch post or that multi-thousand-dollar conference spot to kick everything into gear. And when that spike turns into a blip your motivation is crushed.

The problem is very simple — life doesn’t work that way. Very rarely is the correct solution so simple & obvious that it can be extracted over a weekend, no matter how little you sleep. Democracy is the worst form of government, after all.

Derek Sivers says that ideas are just a multiplier of execution. I’d take that one step further, and say execution is a multiplier of execution. New businesses are momentum machines. Release tiny pieces but release them often, and improve a little bit every time you do. Be happy that you’re trending in the right direction, rather than upset that you’re not an overnight revolution.

The MinuteDock dashboard played a Charlie Sheen quote each time someone signed up for a paying account. We’re not in the same office these days, but when we were it was great to share in that little success every single time it happened.

It’s common to claim a Startup (or any new business really) is a marathon, not a sprint. I’m not sure that’s accurate. In my perhaps overly cynical experience starting something is more like being lost in a desert. You’ve no idea where you are, no idea of where to go, and no idea whether your water will last till that next oasis (if it is indeed an oasis!)

It sounds trite, but you grow one customer at a time. Every step is one closer to the edge of the desert. You should focus on that rather than mirages of hockey sticks or stair-steps.


“If you want something done right, do it yourself!”

A quote from “Some guy, just before he screwed it up himself” according to Yahoo Answers.

When I first trundled across Rails, it was like they’d been watching me work and had built the framework just for me. You had full-featured templates (no more wrestling with Smarty), you didn’t have to write endless, boring boilerplate, and you got to hide the “.php” on all your URLs.

There was only one problem. Rails was written in Ruby, not PHP! You could grab a Dreamhost account for $9 a month, but dedicated Rails hosts were few and far between. Besides, I already knew PHP and the people who were paying me knew to ask for “PHP Developers” if they wanted quick, dirty and cheap (in the short term at least) web applications.

Rails would be great, if only it was written in PHP. Well, if you want something done right…

In the years since, I’ve run across far too many frankenstinian Rails implementations, of varying levels of monstrosity. Inevitably you’ll run into a technical limitation (mine was the lack of late static binding in PHP at the time), or a client who simply isn’t patient enough to finance your own personal quest for the White Whale. Either way, there’s no way you’re going to be able to replicate the work of thousands of contributors all on your lonesome.

The result is a barely-alive concotion of whatever small percentage of functionality you’ve managed to build, and a very unhappy client.

It’s easy to pick on PHP here. My experience of the community is definitely that code packaging and re-use is limited. Each programmer tends to build up their own “functions.php” complete with motley crew of common helper code. Ruby seems to do better, possibly due to the ubiqutiousness and ease of use of Rubygems and Bundler, or perhaps due to the relentess focus on Best Practices from the Rails team.

Not Invented By Me isn’t limited to PHP though, and it’s especially common amongst coders who are just starting out.

So why do we do it?

Well, it’s actually useful from a learning perspective — there’s a reason Computer Science lecturers ask you to implement a bubble sort, despite both better algorithms and better implementations existing. My knowledge of different language implementations definitely increased as a result of trying to translate Rails’ ActiveRecord.

There’s also an evolutionary factor. Mutations or forks can sometimes create their own niche (see Ember, Angular, Backbone and friends) or even entirely replace their parent (see Webkit or, arguably, Ubuntu).

Sometimes, it’s human nature to want to make your own mark, however small and similar to the thousands who’ve come before. There are many like it, but this one is mine.

This is all a rather long-winded way for me to justify giving blogging another go, complete with a custom design on top of Octopress.

No, I’m not quite crazy enough to build my own blogging engine.