The Antipattern Edition

On code, patterns, and networks

We’ve been doing this every day for a few years now. Keen to hear what all of our readers think. You can always reach us at this address. -Colin (CJN)

Noah here. I’m not a software developer, but I’ve had the good fortune of getting to spend a lot of time with smart coders over the years and I like to think a bit of their approach has rubbed off on me. While I’m not in the camp that says everyone should learn to write code, I do pretty firmly believe that there are a set of ideas in computer science and software development that would be helpful if they were more widely understood. These range from relatively simple concepts like how a database works (only simple because databases more or less work like Excel, which many people already understand), to some harder to grasp but important ideas like abstraction, which is essentially a process of generalizing something to make it easier to work with. 

One helpful abstraction in the world of development is the idea of patterns. A pattern is not much more than a good approach to solving a particular type of problem. In web design, for instance, there are a whole host of design patterns that we rely on as users. These include breadcrumbing a page so you know where you came from or including a step count in a checkout process to know how much work is left. The pattern is a simple solution designers can rely on. It’s aided by the network effect: the more it’s used, the more we as users look for it, the more valuable the pattern becomes.

Why is this interesting? 

Over the last few weeks I’ve found myself talking a lot about a related idea: anti-patterns. The term was first coined in 1995 by the programmer Andrew Koenig, who explained, “An antipattern is just like a pattern, except that instead of a solution it gives something that looks superficially like a solution but isn't one.” While Koenig was talking about anti-patterns in the world of software development, I find myself thinking and discussing it most in the realm of organizational design. There are a set of organizational anti-patterns that almost every company falls into and recognizing those ahead of time can hopefully help in avoiding them. 

To give a sense of what those look like, here’s a subset of the Wikipedia list of organizational anti-patterns:

• Analysis paralysis: A project that has stalled in the analysis phase of development, and is unable to achieve support for any of the potential plans of its implementation

• Bicycle shed: Giving disproportionate weight to trivial issues

• Cash cow: A profitable legacy product that often leads to complacency about new products

• Design by committee: The result of having many contributors to a design, but no unifying vision

• Peter principle: Continually promoting otherwise well-performing employees up to a position they are unsuited for, with responsibilities they are incompetent at completing, where they remain indefinitely

• Seagull management: Management in which managers only interact with employees when a problem arises, when they "fly in, make a lot of noise, dump on everyone, do not solve the problem, then fly out"

• Stovepipe or Silos: An organizational structure of isolated or semi-isolated teams, in which too many communications take place up and down the hierarchy, rather than directly with other teams across the organization

There are lots more good ones, but you’ll surely recognize many from that list. Bicycle shedding is a favorite of mine. It originally comes from C Northcote Parkinson’s book Parkinson’s Law, where it’s told through a fictionalized meeting of a finance committee. Item nine on the committee’s agenda is approval for a $10,000,000 nuclear reactor. While there are a few murmurs and we’re told one of the few nuclear experts on the committee distrusts the round number, the item is approved in less than three minutes. Next up is item ten: a bicycle shed.

Chairman: Item Ten. Bicycle shed for the use of the clerical staff. An estimate has been received from Messrs. Bodger and Woodworm, who undertake to complete the work for the sum of $2350. Plans and specification are before you, gentlemen.

Mr. Softleigh: Surely, Mr. Chairman, this sum is excessive. I note that the roof is to be of aluminum. Would not asbestos be cheaper?

Mr. Holdfast: I agree with Mr. Softleigh about the cost, but the roof should, in my opinion, be of galvanized iron. I incline to think that the shed could be built for $2000, or even less.

Mr. Daring: I would go further, Mr. Chairman. I question whether this shed is really necessary. We do too much for our staff as it is. They are never satisfied, that is the trouble. They will be wanting garages next.

And so the anti-pattern of bike-shedding was named (but certainly not born). “A sum of $2350 is well within everybody’s comprehension,” Parkinson writes. “Everyone can visualize a bicycle shed. Discussion goes on, therefore, for forty-five minutes, with the possible result of saving some $300. Members at length sit back with a feeling of achievement.” Putting these items before the same committee seems like a reasonable approach, but as we’ve all probably experienced, Parkinson is exactly right in where the focus and time ends up being spent. It’s an organizational anti-pattern that if known ahead of time can be avoided. (NRB)

Quick Links:

• Myspace Tom got it right (CJN)

• What bullets do to bodies (CJN)

• Why is MI5 on Instagram (CJN)

Thanks for reading,

Noah (NRB) & Colin (CJN)

—

Why is this interesting? is a daily email from Noah Brier & Colin Nagy (and friends!) about interesting things. If you’ve enjoyed this edition, please consider forwarding it to a friend. If you’re reading it for the first time, consider subscribing (it’s free!).