Management, Tech Life More than the sum of it's parts

Signs of Art

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:

Welcome!

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?

10 Responses

  1. As a full time programmer, and a guy who almost got an art degree- I’ve got to say I’ve always thought it should be more like this: Art is a craft.

    Like cabinet makers, etc… it’s obviously got artistic values in it, but it serves a functional purpose.

    I always felt it was best to leave the art label to paintings and such created by folks like Van Gogh, Degas, Rembrandt, Picaso, etc..

  2. Er, not “Art is a craft”, “Programming is a craft”.

    .. must… proofread.. first..

  3. Ah the art of software development.

    Thank you for a great read.

  4. Otis McGrover 11 years ago

    Ah, the age old issue of purpose in art. It’s summed up in this cat and girl cartoon:

    http://catandgirl.com/view.php?loc=244

    I personally disagree with gus mueller and girl. The rands definition is more satisfying.

  5. Long post follows, because I disagree with Rands on the specific point of the customer.

    By Rands’ definition, software is indeed art. But, software must also have some specific use.

    Effort seems to be the most concrete way to judge art. Minimalist modern art would be judged to be poor by this standard. Unfortunately, a Van Gogh painting and a really awful similar painting by a college student might be judged just the same by the standard of effort (decisions made, time invested). A more subjective aspect has to be involved; you might say that art is effort directed by skill. That’s fine if you are buying, selling or appraising art directly as art, whether it is software or matches.

    Usually, though, a customer of software is not directly a judge of effort or talent; they are most directly judge of utility, which is the result of effort and talent that is directed toward serving a purpose. The customer will judge it by whether it serves that purpose. It is unrealistic to expect that a customer will buy your software based only on the effort you put into it.

    So, I’m saying that Rands is wrong when he says that the customer will make the decision, “Is it art?” which is to say they will judge it by how much effort was put into it. What is directly judged is the end result of art and talent as applied to the problem solved by the software.

    But, I may have somewhat misjudged what Rands was saying, and there is a huge body of subjectiveness and indirection involved in the discussion. There’s also a long discussion to be had about “The Iceberg Rule” and object vs. subjective measurement of utility and a million other things. 🙂 Oh well.

  6. frisbeememex 11 years ago

    Boy, was this essay all over the place. Yet hear I am responding. You’ve touched a nerve.

    For me the key nugget in your essay is one of the first lines – “Organics: “You’re right! It’s work but it’s artful work.” It lies in the distinction between that which is “artful” and the semantic morass of that which is “art”. Assigning the status of “art” is irrelevant. Describing a piece of software as “artful” connotes that the team who created it has an appreciation of and aspiration to some ideal of perfection. It’s a compliment to their character. It doesn’t have to fall in line with a particular belief system (organic or mechanic), what matters is that you’re surrounded by believers. Something matters. I don’t know if this inherently produces better or more successful products – believers can still be deluded. I do know that this energy, channeled towards helping/pleasing another, can move mountains. Or at least make iPods.

  7. “The creation of art is not the fulfillment of a need but the creation of a need. The world never needed Beethoven’s Fifth Symphony until he created it. Now we could not live without it.” ~ Louis Kahn.

    The world never needed VisiCalc, or OS X, or Google until they were created, now we could not live without them. Software is indeed art.

  8. Paulo Köch 11 years ago

    Hey, look! It’s somebody’s 5 cents. It reads…

    Rands is right in one thing, software as art involves effort and decisions. Although, being a combination of both, a software might just be art even if it took ridiculously low effort, given that it always took the right decisions.

  9. Otis McGrover 11 years ago

    Saw this article on memepool and thought of this thread:

    http://www.idlewords.com/2005/04/dabblers_and_blowhards.htm

  10. from here http://www.timmfin.net/2006/01/09/art-and-a-bit-of-software/ tried to trackback, but no success.

    Now I don’t agree that this is the precise definition of art (fortunately I gave up thinking there was any such thing as a precise definition of anything a while back), but I do like its approach. And I think it brings up some notions of Art that don’t come with all those dusty textbook definitions from my Art theory class. I’ve certainly heard things about capturing/substance and difficulty/size/complexity but decisions — that is a new vantage point.

    I like the notion of the decision making of/on/about Artwork because if you have ever been in the process of seriously trying to create — it seems like its all you are doing. Creating a mark of such shape, texture or bracketing your shot to attempt to get the exact exposure you want or decrescendoing till the note falls from your lips or designing your software abstraction in such an elegant and comprehensive fashion (well to start at least. we all know that abstractions are leaky and spherical).

    The problem with decisions is that the term feels so rigid. Even the most non-organic of us still don’t think in black and white despite the fact our minds make us think that we do. You could never take a piece of Artwork and create a flow-chart from it. If you could, well… you are super-anal or its no where near a piece of art (moving to lowercase due to laziness). The decisions you make — while very intensive — are more often subtle (sometimes unknowingly subtle) or spontaneous and intuitive. Calculated decision making certainly takes place in artwork. “I like that wash, but I need to balance it.” … “How can I support the weight of that?” …”I need to use higher-speed film/this rated flash for this light.” … But, if you are you trying to create solely formulaicly* you will have a very difficult time (psst.. your subconscious is actually smarter than you think, let it have a bit more control every once and a while).

    Does this mean that software is too black and white to be artistic? No way! …