Back

11000 - Six Things Programmers Would Like Project Managers and Designers to Know

by - Joseph Ganci

1. It's much better to involve a programmer too soon rather than too late. Often, minor changes and adjustments can be made to a design that may significantly reduce programming time and potential problems. To make changes after programming has begun is more difficult and much more time-consuming.
   
2. When you create storyboards, please use a consistent and logical approach to naming your screens. These same names are used in the programming to track the screens and to allow programmers to synchronize the storyboards with the code and to allow debuggers to identify where in the storyboards the screen they are viewing is found.
   
3. Things are not always what they seem. When you request a change, you may already have a time estimate to code in mind without having received programmer input. When the programmer doesn't complete the work in the time thought, the programmer is made to look slow. This is an even bigger problem with designers who have had "a little" programming in their background or taken a class: it. s the old adage of knowing just enough to be dangerous. On the other hand, sometimes you will assume a change will take longer than it actually will: always consult a programmer, especially the ones already familiar with your project code.
   
4. Making significant design changes after the programmer has begun without extra funding will usually mean the kiss of death for the project' s budget and schedule. Programmers try hard to make accurate estimates of time to complete and design changes are not usually included in these estimates. Ask yourself: are the changes absolutely essential to the outcome of the project? If so, be prepared to ask the client for extra funds or to defend why your project is going to lose money and be delivered late.
   
5. The saying "Measure Twice Cut Once" is used in construction work, but can also refer to design. If you are not sure something in your script will work or may be awkward, think it through. Spend a little bit of time visualizing how it will work. This will help avoid wasted programmer time.
   
6. Storyboarding is very time-intensive and the search is always on for ways to reduce the time necessary. However, no matter what method you use for storyboarding, please make sure you are complete in your work. Cross your t' s and dot your i's. When a programmer finds something missing in the storyboards, he or she is faced with one of two choices. They either must halt work until they can find the designer, interrupt his or her work, ask the question, then implement the answer or in the event that the designer can't be found or is out of town, they must make design decisions. This happens more often than you might think and is also not something that is part of a programmer's estimate to complete.