There’s a never ending battle going on in your software development team right now. It’s the battle between the Organic Engineers and the Mechanical Engineers and it sounds like this:

Organics: “Software is art!”

Mechanics: “Software is logic! It’s fact! And it’s a lot of work.”

Organics: “You’re right! It’s work but it’s artful work.”

Mechanics: “When you call it art, you trivialize our work. I design lightweight database libraries and it took my team of four engineers 18 months to roll out last version and it’s compliant with RFC 2354 and blah blah words acronym words blah blah.”

It’s at this point the Organic glazes over and starts dreaming about how they’ll design a stunning application on top of this whizbang database.

As I’ve said before, we need both Organics and Mechanics (as well as Incrementalists and Completionists) to get our bits out the door, but what I really want to say is…

Software is art.

The follow-up to this statement is “What is art?” Brighter folks than I have spent their careers working on this question and I’d like to apologize in advance to each one of them. I’m just some schmoe sitting on the floor of an airport waiting for my flight, but I’m going to take a stab at definition.

Art is “the documentation of a thousand interesting decisions”.

Let’s take that apart word by word:

“The documentation…” In order to qualify as art, you’ve got to be able to share it with others. This means capturing it on some canvas whether it’s paper, a DVD, a web page, a city, or your skin. If you can’t share your art, it’s not art. It’s a conversation with yourself and I’m sure you’re fascinating, but why not share it with the rest of us?

“… a thousand…” A thousand is a swag. It describes that there needs to be some perception of effort for a work to be art. I’m specially YELLING AT YOU MODERN ART because YOU OFTEN FAIL THIS TEST. A matchbox poorly glued to a large piece of purple construction paper is not art. Sorry.

I’m not suggesting that an outside observer needs to look at art and say, “Gee, that looks hard to do. I couldn’t do that.” The observer needs to experience something in the piece whether whether it’s the size, weight, or complexity of the work and can’t be created with a single trivial decision.

“…interesting decisions…” Now, here’s the heart. Art is is when someone captures a set of decisions worth remembering. Blue or red? Serif or sans serif? Ruby or Python? San Francisco or New York? Up or down? As I said above, one decision does not art make (STILL GLARING AT YOU MODERN ART), it’s the collection of all the decisions… captured… that create a conveys a unique idea to the observer. It’s not just whether they can see/hear/feel this idea, it’s whether they find inspiration in their aggregate perception of these decisions. It’s a personal thing. Some decisions will inspire, some will bore and the sum of all the decisions will affect each person differently.

Software is art.

It’s a thousand decisions captured in code and displayed as user interface, services, and any number of other useful and artful conveniences. I would further argue that a great piece of software has equal ability to change the world as any great piece of art and if you disagree, I direct you to exhibit A, B, and C.

Believe it or not, that’s just introduction to this piece. What I really want to talk about is my secret Software as Art checklist. This is my personal list of discrete events I watch for in a team which engaged in the practice of building artful software.

This list will annoy every program management lovin’ mechanic out there. I swear I tried to shake as many of them off with the whole fuzzy (yet relevant) art introduction. If they’re still here, I need to say that I’m not suggesting that the following is a means of gauging a project, it’s a means of taking the temperature of a process which is creating art. I will further frustrate everyone reading by merely giving you a means of measuring without suggesting how to improve your team environment. That’s another column or two.

Measuring Team Art

Teams which are building art display the following traits:

1) High tension at inflection points. Traditionally, folks start yelling whenever you move from one development phase to the next. Sometimes there are formal meetings around these transitions, sometimes not, but what I’m looking for in the yelling is a team that is choosing to challenge the process.

If you’re moving from design to development, folks should be asking questions like, “Do we have the right features?”, “Has anyone bothered to write specifications?”, or “I don’t understand the vision for this product.”

If you’re moving from developing to deployment, the questions are different, but similar in tone, “Have we fixed enough bugs?”, “Do these features work?”, “How’s our Beta going?”, or “Does anyone else but me think this is crap?”

The key to this tension is not that folks are tense, it’s demonstrating that they are engaged. They know these development inflection points are critical public decision points and if they’re taking the time to care then they’ve got skin the game. Art is never created by those who are following the process.

2) Ideas appearing out of no where. Love this. You’re wandering the hallways on a Saturday afternoon and two engineers are idly talking about Feature X. It’s a casual conversation, so you plant yourself against a wall and listen in and WHAM HOLY SHIT she just totally redefined Feature X with an off-the-cuff comment. SOMEONE WRITE THAT DOWN.

As I mentioned in the Taking Time To Think piece, great ideas only come when you’re soaking in a problem. Hallway brilliance only comes when the team is breathing the product.

3) Efficient Decisions. Another good sign that folks are busily creating art is they are making their own decisions. This might be hard for a manager to swallow because you’re getting paid to lead, but, trust me, you want the folks staring at the code to know two things:

• They can make strategic, big decisions all by themselves, but…
• The more folks they involve in the decision, the more art they create.

When you combine “efficient decisions” with “ideas out of no where”, you’re really cooking. A lot of folks freak out when they see a brand new feature in the product two weeks before the feature complete milestone. Yeah, it’s called feature creep and it’s hard to ship a moving target, but it’s worse to ship bits that are uninspired.

4) Evening and weekends. The traditional senior level productivity measurement is, “Is the team working weekends?” Senior execs believe a team really needs to “burn it at both ends” to ship a product. Furthermore, they believe that providing food for said weekend week is an incentive. Here’s your wake up call folks:

No one ever worked a weekend for free tacos.

When it comes to weekend and late night work, the question is not “Are they?” the question is “Will they?” Success here is a simple measure. Does the team go the extra mile without being asked? You see this behavior in start-ups all the time because the team knows who the team is. “It’s me and these three other guys and if we don’t do it, no one else will.” In larger companies, this perception is diluted because there is so many frickin’ people. It becomes, “Well, someone is going to fix this, right? Right?”

Measuring Despair

At every entrance to the Silicon Valley there’s this huge road sign. It reads:

You’ll notice that the sign says nothing about art. That’s right. You can do better, faster, and more and make scads of money without a smidge of art. Is that company you want to create? To work for? Really? Bummer. You can stop reading now.

If you’re still here, you know that the combination of a desire to build art and the BetterFasterMore mantra will invariably lead a development team to believe it’s screwed. No matter how inspired, creative, or innovative the group can be, they will arrive at an psychological impasse where all will appear lost. This is where you, the manager of people, will realize a couple of things. First, even though you’re no longer contributing code, the decisions you make regarding moving the team past despair is your essential contribution to the art that is your software. Second, you are responsible for the flavor of despair the team is experiencing.

One flavor of despair tastes like that last sip of coffee that’s been sitting in that paper cup all day. Cold, useless, and full of coffee grinds. It’s got a hint of promise, but it’s mostly an empty reminder of what was…. it’s depressing. The other flavor of despair is metallic in taste… it’s the flavor that floods your mouth when you’re being chased by a bear. It’s scary, but the adrenaline is kicking in and that means SHIT WE’LL JUST RUN FASTER.

There is a flood of management terms which change the taste of despair. Empowerment! Collaboration! Thinking outside the box! These words pasted on big fat pieces of paper and slapped all over the building do exactly one thing: they clutter up the joint. Changing the taste of despair and building a team that wants to create art is a full time gig and I’ll spend a lot of time writing here about how to do it. Sorry to leave you hanging, but I’ll leave you with a simple observation.

If you’ve got a team full of bright artful people, they’re going to have endless opinions about what is art and what is not. They will argue, they will yell, and there will be times when you hate the person you respect most because you are incapable of admitting they are right. This roller-coaster of pain and pleasure always ends at the same spot. It stops when all of the team’s hard-work is judged by one person — the customer. A finicky, opinionated person who will make the most important decision — is it art?