Friday at Four: Boosting Productivity by Avoiding Anti-Patterns

Fridays at Four are Xdesign’s group hangout session in which we set out to learn something new and improve the team. These discussions can range from a TED Talk to the latest in design or typography trends, to just taking a break to sit outside in the sun. This is John Gibby’s talk on increasing efficiency through avoiding implementation of anti-patterns.

A little background

What are design anti-patterns? Sourcemaking says it is:

“... a literary form that describes a commonly occurring solution to a problem that generates decidedly negative consequences. The AntiPattern may be the result of a manager or developer not knowing any better, not having sufficient knowledge or experience in solving a particular type of problem, or having applied a perfectly good pattern in the wrong context.”

Basically, Anti-patterns are The Devil

I wanted to go with Anti-Christ but felt that’d be a little too cheesy. Anti-patterns are the source of frustration in most environments. However, these are not exclusive to coding. These friction points can occur often and anywhere. Office, home, soccer game, wherever you are and you have a strategy to implement, anti-patterns can rear their ugly head.

These efficiency busting, frustration causing, bang your head against the wall issues are productivity killers. Instead of designers, developers, managers, executives, etc. focusing on their jobs, they are forced to either interact with an anti-pattern’s frustrating side effects or stop what they’re doing to try and fix the problems that an anti-pattern creates.

We’ve all implemented an anti-pattern, here’s mine.

A few years ago X had a file challenge. We needed the ability to use one unified file system, to have off-site backup of our files, and to be able to access those files from anywhere. The first solution proposed by me was, indeed, an anti-pattern. What I designed and implemented was the following network structure:

The idea was that two main computers would connect to dropbox on their own. Then there would be two production computers who would connect to a central server. The server would would connect to dropbox on its own. IT guys all over are looking at this plan for what it is – a disaster. But – it did address all of our desired goals. Unfortunately, it did so without enough research or planning into what the best solution would be to achieving our goals.

Once the anti-pattern was defined (after a lot of angry looks my way), a true solution was presented.

Just looking at the visual design tells you that this solution is much simpler and much better. People inside of our network connect to a server. The server then connects to dropbox. The individual accounts in dropbox are accessed remotely on an at-need basis. All goals are achieved with none of the new problems introduced that our first anti-pattern was responsible for.

Beating Anti-Patterns With Patterns

Identifying anti-patterns and providing proper patterns comes from experience and wisdom. Any company like X is responsible for providing their clients with good, strong, professional work without introducing new issues that the client will have to deal with. In order to provide that level of professionalism, it must start with us. With 24 years of experience under our belts, you can bet we’ve encountered this a few times.

With our 24 years of experience, and our talented team full of new ideas, we have taken a top-down, problem identifying – to top-down problem solving approach according to the following pattern:

Problem Identification
When we are constantly working on new and better things, inevitably we will encounter something new. This may cause a hiccup in productivity for any member of #teamXdesign. When these hiccups occur, they are identified for research.

Research
The best beginning to avoiding an anti-pattern is to start with researching to see if a pattern already exists for your issue. But what What are patterns? According to this article by tuts+ they define patterns as :

“Design patterns are, by principle, well-thought out solutions to programming problems. Many programmers have encountered these problems before, and have used these 'solutions' to remedy them. If you encounter these problems, why recreate a solution when you can use an already proven answer?”

Distilled down that means basically this: Don’t reinvent the wheel. The internet is a beautiful place. Just as we are posting our experiences with this blog, others are also sharing their knowledge and experience with their own experiences. If we can identify a hiccup experienced and reported by others, #teamXdesign will take relevant details and present them to department leads who will then set about methods of implementation.

Anti-Pattern Testing
After research is complete a plan will be written. This plan will be distributed between department leads and relevant #teamXdesign members. Just like someone who wants to color their hair, we will then test the hopeful pattern on ourselves (this very post could be an example of testing a hopeful pattern). After careful consideration of the test, the solution will be identified as helpful, needs work, or the dreaded anti-pattern.

Implementation
If our implementation passes our self test it is then written into X Policy (sounds fancy). In fact, as hinted above, this very post is the testing of a new branch of our Social Media/SEO Strategy. This little solution has big dreams of becoming a pattern implementation one day and it is now up to the wild to see.

Let’s see how much traction this gets, maybe even leave a comment if you see any new problems introduced!