Playing with others
It's difficult as a programmer to work with artists. We develop things in completely different
ways. A programmer likes to build the
software and then go live with it, when it's finished and bug-free. Artists like to tinker with things, roughing
out their work and then touching it up.
They don't mind checking something in half-finished or coming back to it later.
In fact, that's how they work best.
Developers and artists on a production team are strange
bedfellows. And what can you do, as the
programmer? You've got to give them
something to play with! This
relationship adds a new level of complexity to the design and growth of the
technology. A new dimension. Suddenly, I'm re-thinking designs to avoid
changing the file format of a particular asset, lest we'd have to re-save
everything. Everything is
production-quality, all the time.
Which... is actually wonderful.
But it's quite demanding.
If you've ever been in that situation then you know jes'
what I'm talking bout, as Eddie Boyd once said, as he went back to writing his
production quality code.
You need a plan, if you want to build a piece of software
that will be incrementally functional.
You want it to be usable ASAP, so your end user can get to work as soon
as possible. But you also want it to be
massively scalable, and it better be consistent. But most interesting thing to me is how the
artist mentality overcomes the direction of the product. Suddenly, the software is a living
paintbrush. Just as the scene is getting
iterated on, so is the software.
Features get and lose support as they fulfill their level of need from
the end user, who is giving feedback in realtime during the development
process. Designs change and change
back. It's dizzying if you don't have
the right footing, and that's why the plan is essential.
The other half of the battle is Shock and Awe. Often you can
get the user to go your direction on a certain feature by impressing them with
what it can do.
Anyway I've been drinking and this entry is a stub. To Do