Don't worry about breaking the abstraction

Having a good descriptive metaphor to guide your design will help you immensely! Abstracting your thoughts into a metaphor provides an already thought out solution to solving a design problem, and thus also hints to which paradigm solutions to unexpected challenges might be found in.

Just as developers use programming design patterns to to solve their problems, developers often make good use of metaphors to abstract out complex problems to something more familiar, concrete, and more manageable.

One of the more obscure abstractions I’ve made in my programming past was a SubscriptionJanitor class that through a cron job did daily clean up in the database, marking subscriptions with failed credit card transactions as disabled. Over time, the janitor took on more responsibilities and soon did more than just dealing with subscriptions and just janitorial duties, thus rendering its title obsolete. He was in for a promotion. The abstraction was broken and a new one had to be found.

As your design evolves over time, your will possibly also be bound to break your abstraction at some point in time. Don’t be scared. Find a new abstraction and possibly also a new metaphor to describe it. Too many designers and programmers are too fond of their own creation to break it, and thus prevents their line of thought to go beyond the metaphor. They will not break the abstraction even though sticking to it will hinder further innovation and progress.

Falling in love with your own creation – with your abstraction – will hinder you. Don’t fall in love with it, but be ready to move on when the time is right. When you start seeing yourself rejecting suggested features as they will break your precious baby, then it’s time. That’s a good sign. Don’t be scared to break it. It might just be time to move on.