A painted parable on programming...

TechNinja's picture

Imagine for a moment, if you will, that you are a painter. A fairly skilled painter in your craft, not the best, but good enough to get by in almost every situation.

One day your client, let's call her D Debbra, commissions a painting. She's been in her business a long time, and considers herself smart with the terms and commonalities of painting, though she does not paint, she visits seminars and has seen and managed people who paint. "I want a painting of a dog. A brown dog." she says tersely, "I need this for the front office, it's going to need to be very good. ". While she's there, you do your best to work out approximately what the dog will look like, maybe what it's standing on, and eventually the client leaves you with the semblance of a spec. You get to work.

A week later, Debbra comes in and asks to see the painting so far. Having done most of the ground work, you've already put down the paint after framing up the sketch and have been cleaning up the lines to get it looking about right for final clean ups. The client says "Oh, that's not bad.. though. Is that grass the dog is sitting on? I we need that to be tile. I've been to many high cost painting conventions where they say dogs should NEVER be portrayed sitting on grass! More people will look if the dog is sitting on tile. Don't you know anything? I thought you were a good painter!".

A painted parable on programming...

You attempt to explain to her that it's going to take some time and quite a bit of repainting to change the grass; some of the dog might also need to be redone because of the overlap. Of course it would have been easier if that was originally part of the spec, but Debbra had changed her mind, or simply did not provide the information from the start. "What's wrong with you? It's easy! I can see the changes in my head. Why can't you just make them happen? I don't see the problem here. Maybe your paints are all wrong, and your brushes too. I can't believe I'm wasting money on you when it's obvious that your brushes and paints are screwing me over!"


My canvas is a server, my current paint is MySQL and PHP. My pencils, pens, brushes and other tools are Drupal/PHP. As a painter or a programmer, the end result is simply the art of putting everything together to achieve the intended output. Perhaps the failure noted in the not-so-fictional parable above, lies simply with the painter's inability to capture a complete speculative requirement from the client. Of course, even if the painter had done everything in their power, the chances of moderate change by the next meeting are high given the nature of art, and most certainly the nature of demanding clients.

The problem is not then that a "moderate change" is bad or difficult, the issue becomes that a "moderate" change in the eyes of someone who has not painted the painting, can either be easy, or an incredibly difficult challenge to the painter based entirely on how it was made by the painter. If the painter thought ahead and painted the dog on transparent plastic, then changing the background is a simple matter of painting a new one and overlaying the pooch on top.

Of course, it is not the job of the client to know the hows and whys of painting, or to even know or understand that painting on plastic saves time for background changes. Perhaps it should be the job of both client and painter to make it clear to everyone involved, of everything that's going to be needed, and anything that might change, and in what direction.

Like that's going to happen!


A number of the points I make in this blog entry probably come from an awesome book I read about 5 years ago, called Hackers & Painters. Give the link a read for further musings on the analogy gone too far.

Tags:

Comments

This is one of the fundamental issues that always arises with being a comissioned artist - or really for any person that provides the service of bringing to life something that lives inside the imagination of the client. I have learned this lesson the hard way many times now and each time I make it a point to try to prevent problems from the start of each new project.

I get visual references from my clients, and get them to explain in detail what they want. This can sometimes be difficult for someone who is not a visually driven thinker, or for someone that knows nothing about the process. Sometimes I have to really coax them into describing in more detail for me when all I get is "I want it to be pretty!"

I put the description in writing and verify all the details. Then I explain the nature of reworking the art. Minor changes can be easy and done for no extra charge, but if their mind is changed drastically I will have to charge them for re-draw time. Knowing they will have to pay for each re-draw usually prevents them from continuing with a project if they haven't made up their mind yet. This saves the both of us from misunderstandings and delays.

Actual art, I'm led to believe, has a positive stigma towards freedom of expression. Something that to the general public, and especially to those set in charge of programmers, the opposite seems to exist. With guidelines and rules and strict standards, freedom dies a cold lonely death in the corner of a cubicle.

Except perhaps in comments; my coworker recently showed me some code made by a past employee, using a "Wizard" type application to move through a large complicated form, if includes little tidbits like

Do not meddle in the affairs of wizards, for they are subtle and quick to wrath.


Classic. I have yet to achieve mastery in code commentary art, I hope one day to be proud of my coding legacy. (and not just consistently bothered by it)

Jamey, you are the awesomest ever :)