Abstraction and Customisation

Ashim D’Silva

19th May 2013

We just went through renovating our office space: cut our large table in half to make room, rewired to reduce stray cables, giant whiteboard, better lighting and cooling… the space you work in is important, and improvement is never complete.

What I’ve noticed with every little detail though, is the modularity of components available to assemble your customised template. And the immediate difficulty in dreaming up something that doesn’t fit the acceptable standard.

From the whiteboard to the electrical sockets, curtains to the woodwork, there are standard sizes and processes to ensure fewer mistakes, quicker turnarounds and cheaper manufacturing, often at the cost of an ability to customise. For example, to get a frameless whiteboard, you order a regular whiteboard and remove the frame!

We do this all the time with technology. In order to build in the shortest (cheapest) way possible, we combine existing pieces that roughly fit our goal, and sand off the edges to squeeze them in. When we’re building tool, we try and abstract the problem definition so the piece is reusable at a later date. This makes for an efficient build cycle, but often results in a product that only acceptably fits the requirement, it isn’t designed to fit.

I’ve mentioned this before around food and a well-tailored suit–in the luxury market, hand-made and expertly crafted is the name of the game. But what of the rest of us, can we break down our needs into patterns that warrant repeating? Or should we build many specific solutions to the variety of problems that exist so the selection of components already suits you better?

Is there enough of a market for your unique problem to result in a pre-produced solution? Because if there isn’t, your alternatives seem to be make do or build from scratch.

more posts