The Complicator’s Gloves

By Jake • October 16th, 2008 • 8 Comments

Thanks to Chet “for great” Justice, a.k.a. ORACLENERD, for passing along this gem from the Daily WTF.

Alex Papadimoulis lists three types of developers attacking good software development, the Amateurs, the Career Amateurs and the Complicators.

The Complicators are the focus of the post; I love the description:

They’ve acquired a sort of sixth-sense: the ability to find meta-problems (“a problem with the process of creating a solution for the actual problem”) in virtually any solution.

Anyway, I highly suggest a bounce over to read the post, very amusing. Anyway, Chet thought it would be fun to start up a shame site dedicated to everyone’s favorite “meta-problem” creators. I agree, and I think it would be wildly popular as layoffs put developers out on the street.

Aside from the inherently snarky and mean side, a site dedicated to over-engineered process would be carthartic and fun to read, kinda like watching Office Space, again.

The story of the “hand warming system” reminded me of the energy and fervor that a group of motivated people can put into solving Life’s big problems, like how to keep the kegerator stocked.

Before we jump in the wayback machine, this isn’t a meta-problem example. It’s just an example of how smart people can apply a lot of brainpower to problems that interest them.

Ah yes, let’s go back in time to a time of promise. The year was 2001.

At the time I worked at a startup that provided managed services to monitor all the infrastructure, hardware and software, required to run a website. The company was stocked with rockstar talent in development and operations, really smart people.

As was custom at the time, the kitchen had a kegerator. You know, for beer bashes, late nights, happy hours, or just plain drinking for drinking’s sake. Good times.

Someone felt that a company whose strength was in monitoring the status of “infrastructure” should have a way to monitor the keg’s fullness. Setting alarms based on the keg’s fullness status, the system should send alerts and automagically place a reorder when the fullness dipped below a critical level, which was configurable natch.

A large group of us agreed. Consider the risk of an empty keg (gasp!). So, we applied a lot of effort to the problem. The software side was easy because we already had the engine, monitoring dashboards, alerts, etc.

The hardware was the sticking point because we needed a very specific scale, one with an interface we could hook up to the network, small enough to fit in the kegerator, but with enough capacity to support the weight of a full pony keg, about 85 pounds. You know you were wondering.

At the time, serial port was the way to go. These were rare, but someone (the CTO, I think) tracked one down on eBay. Before we could pull the trigger, someone put an end to all the fun/madness, and we all went back to work.

Or something, this was right as the air was wheezing out of the dot-com Bubble, taking all the joy out of work with it. Oh, and it took the work out too as the company went through several rounds of layoffs before being acquired.

Anyway, this isn’t a story meant to:

Nope, it’s just me waxing nostalgicly about this one time at band camp when a bunch of us got together and tried to solve the empty keg problem.

It’s pretty amazing how motivated smart people can apply energy and thought to a problem they’re interested in solving, and it’s equally amazing how frequently the problem clouds the ability to see beyond the details.

Anyway, your thoughts? On the Complicators and their meta-problems, on the “hand-warming system”, on my empty keg story? On something else?

Find a home for these thoughts in comments.


Possibly Related Posts

  • http://bexhuff.com bex

    Its not a bad thing that developers get obsessive… frankly, that's why they are so valuable. However, it is a humbling reminder that intense focus almost always means a loss of high-level perspective…

  • http://theappslab.com Jake

    I'm agreeing that obsession is generally good, e.g. when it automagically orders you a refill keg. This general idea has teams at big electronics companies churning out smart appliances for the kitchen of the future.

    I'm guessing that only Complicators exhibit the combination of intense focus on meta problems. Most developers I've known are pretty good at seeing the forest, at least in other's work, e.g. peer programming.

  • http://bexhuff.com bex

    Thank you for the email!

    I will be traveling this week, with limited access to email. I will reply when I return.

    –

    Brian 'Bex' Huff <bex@bexhuff.com>
    Chief Software Architect, Bezzotech Inc.
    Developing applications with Stellent? You might find my book useful:
    http://bexhuff.com/books/stellent-dev

  • joel garry

    I was at one electronics manufacturing company that was transitioning from entrepreneurial to mainstream. They would still let the engineers work on creative things. The director of engineering came up with an idea – a device that would take ambient sound, perform a fast fourier transform on it, mix up the bits, and echo it back out after a short delay, sounding like r2-d2. They created a run of chips, had all girlfriends and wives donate empty L'Eggs containers (about 100 IIRC), put little feet and faces on them, and gave them to favored friends. Not a big deal in these days of dancing flowers, but quite the novelty circa 1980. I really wish I had scored one. The fellow who did the FFT later wrote Lisatalk and other famous things. And you shoulda seen the security system around and through the director's house.

    Moral? Complicators are indeed useful, both for increasing team cohesion and exercising creativity that can be a foundation for future endeavors.

    And if you've ever had insufficient gloves, you might not agree with the wtf.

    How many of us have had a PHB way oversimplify a design because, hey, dbase didn't have all these complicated relational rules?

  • http://theappslab.com Jake

    I'm not seeing the Complicator in your story. Creativity isn't the mark of the Complicator, at least how I read it.

    Maybe we missed the backstory on the gloves, e.g. maybe they were too bulky to work the bike brakes. So, assume the story is borderline.

    The Complicator creates meta-problems, e.g. “a problem with the process of creating a solution for the actual problem”. There's a difference between creativity, intense focus and meta-problems. The complicator may exhibit all three, but it's his/her penchant for meta-problems that can derail a project.

  • http://www.oraclenerd.com chet

    Love the pics. Wish I had a camera back in the day when we would pile 5 kegs in the back of my jeep for football weekends. I lived this close to the football stadium.

    Obsessive is good. I am obsessive to the point where I can't sleep until I solve a particular problem.

    What the story tries to illustrate I think, are those that take it way too far. A colleage of mine once relayed a story to me and it goes like this:

    A small two man county shop with a public facing website. APEX? Nope. .NET application (not so bad in and of itself) with an Oracle backend. In order to add a column to a simple report (4 seconds in APEX), their change consisted of:
    1. Add the column to the function that returned a ref cursor.
    2. Add the column to a stylesheet (not sure why, XSLT?)
    3. Add the column to the .NET class
    4. Add the column to the calling application
    * I'm pretty sure there were others, I just can't recall all the steps. Point is, there were a lot.

    2 man shop. County. Wouldn't simple be better? Yes it would be ideal to have the presentation layer loosely coupled with the data layer or even the middle tier. But is that practical?

    This guy created a behemoth of an application either because he didn't know any better (probably) or he was trying to create job security (less likely, I think).

    Keep It Simple Silly (Stupid). That should be our mantra (unless the situation dictates otherwise, i.e. software that could kill you, applications that control planes, NASA)

  • http://theappslab.com Jake

    It's funny, as much as we crave simplicity, software tends to become difficult, especially as you build onto previous versions.

    I wonder what would happen if you completely threw out backward compatibility and supported data migration only, how much better (or worse) software would be?

  • http://onlinemerchantsearch.info Credit card machine processing

    Many thanks for this excellent post. It contains lots of facts which I have to have. I’m going to bookmark your website by my next check out.