Moojive's Official Blog
When you’re a developer in a young startup you are often faced with implementation decisions. You know how you want a module to function or appear to the user, but there might be multiple avenues to achieve that result and there’s no one obvious winner. You weight up all the factors like the tradeoff between getting something up quickly that functions 75% of the time and something more robust, but takes 4 times as long to implement (and one isn’t a strict superset of the other).
Included in this decision process can sometimes be how long you want to spend deciding. You might not know enough about one or more avenues and you need to do a little research or even feel like you need to implement one or more to make the decision. In academic research, by definition, you are encouraged to try all avenues to find the absolute best one, but in an early startup you don’t have such flexibility with time. In a startup it might sometimes be better to decide upon what turns out to be the second best way of doing something rather than spend a heap of time finding the best. This feeling became eerily familiar when out on my midweek run this week.
Every Wednesday afternoon over summer I travel to different parts of Sydney to do Orienteering (check out photo taken from Checkpoint 15 looking out over North and South Head of Sydney Harbour). It’s actually a very fun sport that many people mistake, upon hearing the name, as an activity you might find at a bush survival camp. (My brother calls the sport girl scouts). It’s nothing like that. Think of it more as a treasure hunt for grown ups. You get given a map, a clue sheet and an electronic stick. The aim is to try to visit as many checkpoints on the map within a 45 minute period. Checkpoints come in different point values, so some are more valuable to visit than others and you are penalised for every minute you are late. (The electronic stick is used to “check in” to each checkpoint to prove you went there, incase you were wondering where that came in). They do give you a little time to plan a general route before you begin running, but you can never know how that plan will actually fair until you get out there and run.
The first time anyone does orienteering in this flavour, they usually look at the map for 1 or 2 minutes then just start, having only planned their way to the first checkpoint. I did the same and I found after my first few weeks of doing it that I was no where near the top runners each week (there are some absolute gun runners who turn up, but I didn’t think I was that far off in terms of fitness). I found that I wasn’t really pre-planning further than the first three checkpoints, so at each checkpoint I’d stand there for 15 seconds and see where to go next (over about 20 checkpoints that adds up to 5 minutes that I could be running an extra kilometre). So I started doing much more planning before I started and left the actual 45 minutes for running a set course.
There are still some unknowns that make it interesting each week like planning more conservatively if the course looks hilly or has a fair amount of off-road sections, or even how fit you think you feel that particular week. If you come in early, that’s wasted time and there’s no bonus for that. If you come in late, you get slammed with penalties. There’s even weighing up whether on a smaller map it might be better to run overtime as you might just be able to score points at a rate higher than the rate at which you are penalised. You get better at judging these things over time, but some weeks still catch you out. As an experienced developer you generally know how long something might take you to build to that magical 85% mark, where enough things are in place for you to functionally test it, but you wouldn’t release it to a user. (Unfortunately the other 15% usually takes 85% of the time).
Here’s where the analogy gets interesting. Even though I now spend a good solid amount of time planning a decent path each week (and score reasonably well) there are still factors that just spring up and screw you over. You might run all the way up a long steep hill only to find the checkpoint stolen, or just so well hidden that you spend precious seconds trying to find it (there’s no way to fix this and it’s just unlucky - move on quickly). The worst is when you just get lost and lose your position on the map (it’s completely your fault, there’s really no way to get back from that and you just have cut your loses and head back to the finish if you want to maximise your score). The one that I find fun when it’s well executed is when you get halfway around your planned route and you get the feeling you’re going to be severely late if you stick to it. You need to re-plan a decent path home without spending too much time planning.
The best results I’ve had in these time critical ad-hoc situations is to do a quick scan of 2 or 3 immediately obvious, generally about the same scoring, paths back to the finish, then pick one and just stick to it. If you’re standing there looking at your map, you are getting no points. If you’re at least running on a path that’s semi-decent you’re accumulating points one way or another. Deliberation and indecisiveness chews up time in this situation.
Similarly in a dev start up, if you know there’s a way of doing something that’s probably in the top 3 best ways of doing that thing, then just do it. The great thing a startup has over orienteering in this situation is that if enough people like that feature, then you almost get a do-over or at least time to refine the current solution later. In orienteering if you screw up one week then that week’s a bust and you have to wait until next week to do better.
Of course, if you can simply run faster or dev more efficiently then your options are going to be more flexible.
-Steve
