Out of the box or Outside the box?

Scott Francis
Next Post
Previous Post
These two phrases are two favorites in IT circles.  In the first case: “what can we do out of the box?” – an effort to explicitly stay on the beaten path so as to make sure everything you do is supported.  In the second case: “think outside the box, what else can we do here?” It matters which mode you’re operating in… This is one of the hardest judgment calls for technical people to make in their jobs.  And yet, often they make this call without consciously thinking about it.  When should you use some feature that comes “out of the box” but doesn’t quite fit your needs or wants, and when should you roll your own feature “outside the box” by thinking of other clever ways to do it? I think it is a pretty common assumption that it is harder to build things “outside the box” – because at least in theory, the box has value (someone paid for it after all, in most cases).From a pure coding point of view, that may even be a correct assumption – that outside the box is a bit harder.  But from a design and creativity point of view, this simply doesn’t hold up. In fact, it often takes more creativity to operate within the box, within a structure. And a lot of developers will gravitate toward the hard problem, the challenging problem, that interests them.  A consultant will typically gravitate toward the solution that looks like the shortest or simplest path from A to B.  Either approach could be wrong, depending on the circumstances.  I used to joke that the difference between software developers and software consultants, was that it drove consultants nuts to write code to solve the same problem over and over again, even if the technology landscape was different – they wanted to see truly different problems.  But a software developer loves nothing more than an opportunity to write the better mousetrap, and each time to take what they learned from the last effort and maybe utilize some new libraries or patterns in the new effort.  I’m not criticizing, these just happen to be the differences I’ve noticed.  In the context of the statement I made above, I was comparing how I had to manage my developers and consultants a bit differently, in terms of expectation setting, even if I assigned them the same work, and they had the same set of technical skills.  Often people who can build “outside the box” are revered in the organization, and their “built-from-scratch” examples are badges of honor.  Often people who build using “out-of-the-box” features are assumed to be taking the easy way out. Back to the point about creativity inside the box… Consider poetry – an English teacher once taught that rhyming poetry was amateur.  And there is a point to what they were saying – a rhyme tends to draw you into cliche phrasing, and if you’re not careful as an author, even sing-song.  And yet, how do you explain poems like Annabelle Lee by Edgar Allen Poe?  One could argue that writing real meaning in the confines of a specific formulation is more challenging than writing meaning in a less constructed format like that of e.e. cummings. In software, sometimes before one ventures outside the box, a moment of reflection about the out-of-the-box capabilities and features is worthwhile.  Generally, building using such capabilities costs less, and leverages existing support contracts.  Building from scratch or outside the box may not leverage these same support contracts, and often incurs more up-front development cost as well.  However, there are times when building outside the box can actually save costs now and into the future. As stated in the intro, this is a judgment call, and it is one of the hardest ones to make as a software developer.  I’d just like to see these decisions more often based on busines rationales rather than purely technically-focused rationales.  For example, let’s not talk about the speed of the code and the size of the browser download, so much as about the impact on the business in terms of their processes, their costs, or their efficiencies going forward.  Once we’re to the point of choosing between technical options that have nearly identical business outcomes, then we can pick the solution that makes pleases our technical motivations.