Computationally Expensive (within project planning)

When I first started working at foursquare I heard this term as a way of explaining that some things were not possible (right now!) but could be built in the future (soon!).  It is one of my favorite terms for a lot of reasons, but mainly because of the challenge of overcoming whatever obstacle is in the way.

For different groups to understand what is possible and what is not, a matrix of sorts is needed to quantify why things may or may not be possible.  Things like an overall Company vision and roadmap contribute to why and when things are happening, but scoring things can also bring some much needed transparency into the process.

At first glance this seems like an excuse as why not to get something done – simply blaming “its too computationally expensive” – but as you can see there are a myriad of reasons.

I am far enough away from the time when this was first discussed that I have started to think about the issues that came up in another way.  You can easily plot the overall Difficulty and Impact of a project by plotting them on a graph similar to the one below.

Each dot represents a potential project or feature

Scoring would work such that;

Green = justification for immediate completion
Yellow = decide based on subjective views
Red = justification to wait

You can see how almost any discussion between groups, such as BD and engineering, could be plotted on this graph.  Something that has extremely high impact but is technically very difficult (red) may not get the hours/work necessary in light of other projects.  However something that is high impact and low difficulty (green) could get prioritized right away.  Using this methodology brings in some objectivity that may otherwise be absent from a discussion.

There are many subjective reasons why something may end up in a specific area or color, but this at least lets you plot all projects accordingly.

As an organization grows, this allows you to weigh the ideas and complexities of partner requests with that of folks who have longer term (cross quarter) projects currently in motion.  Things like engineering hours, PM resources, and design may play a role in the score and color of a dot.  Previously running projects have probably the highest impact, but provide justification on a high impact low difficulty project being pushed off a month.

Everyone in the organization should understand how a suggestion or feature improvement could affect the overall goals and timeline of a Company.

I don’t think I will stop contributing grand ideas to the product and eng. teams here anytime soon though 😉

As an aside I was reminded of this recently while watching @cooperb give his talk about our infrastructure stack on MongoDB.