Software Development Isn’t an Art III
One pitfall that programmers typically fall into is the need to just dive right into the code. (And production code at that.) They’re in such a hurry to do the job they enjoy the most that they fail to consider how to do it best. That means design. That means analyze the problem before you try to code the solution. That means test what you’ve come up with to validate it before you attempt to codify it.
Pulling examples from the animation profession again, here is a list of the test processes and artifacts used to validate the direction the production’s elements are going (or get it off the ground). There are story treatments, scripts (AKA screenplay), storyboards, and animatics (leica reels) which go through constant revision. There are concept drawings and paintings, character sketches, model sheets, maquettes, set designs, and color teststo develop the look and feel of the film. There are musical scores, bar sheets (AKA dope sheets), and exposure sheets (X-sheets) to work out the timing of the vocals and music with the action. There are layouts to determine camera angles and how motion will be staged.
Even after all this design and timing work has been done, an animator will thumbnail how his drawings will progress before actually beginning (or if he needs to, rethink) his drawing. As far as the animated drawings are concerned, there are roughs which are pencil test and studied before the inbetweens which are then cleaned up before the final ink & paint, and none of these drawings are even seen in the final production. In CGI they use wireframes to review the animation and camera movements before a scene’s rendered frames are generated.
As software developers, we have quite a few tools available to us to speed up the development process. There is the ol’ flowchart and pseudocode. Or we can go with a more in-depth, and sophisticated, Nassi-Schneiderman, Warnier-Orr, Jackson Structured Programming, or UML diagramming notation.
There are Story Cards, CRC Cards and my personal, more permanent, whiteboard substitute.
We can write Use Cases, Unit Tests and Functional Tests (also known as acceptance tests).
There are even Spike Solutions and Prototypes to test ideas, not just UIs, before committing too much effort and cost to the wrong direction.
How many of these or other non-production materials do you use to design your software and provide documentation for new members to your team (think agile communication that scales)? The importance of these tools in improving the quality of your code cannot be understated. Better designs make for better code.
If you read the comments for the link to bar sheets above, you’ll see that this issue of pre-planning strikes at the heart of the quality of the final product. Particularly this comment (which I’m reproducing here because Safari doesn’t scroll directly to it):
Stephen Worth said…
The most sloppily drawn, poorly timed television programs have the highest budgets. It doesn’t cost any more to draw well and plan out your timing. In fact, careful timing can save money…
It eliminates the need to “trim” shows to “make them play”, cutting down on the amount of wasted animation.
If action is timed to a beat, even if it’s a bit slow or a bit fast, it still feels “right”. When you time with no rhythm, you have to do multiple pencil tests and revise your work to parallel park it into looking “natural”.[Emphasis mine. — AG]
Animation is the one medium where every single aspect of what is on the screen can be carefully planned. [O RLY? — AG] If a director chooses to ignore some aspect and let it go to chance, that just means he’s a lazy director. It has nothing to do with money.
We have quite a few tools available to us as software developers. We just need to exercise the discipline to use them if we’re going to raise the quality of our work and be recognized as a true engineering profession.