Although some programs are better at certain things while other programs excel at other things, I noticed that most programs don't get the credit they deserve. This may be because not everyone on a project understands exactly what the tool can do, and of course we all have to deal with people who think the tool can do everything and have it finished in an hour too.

Despite some bugs in many programs, when you sit back and look at what is possible with these tools it is really quite amazing, what they are capable of. While I can't give you a magical cure for dealing with people who can't deal with the tools, I can tell you some signs to watch out for to avoid trouble down the road.

Does your team complain about the Authoring tool constantly?

Are they frustrated that they can't do something, even though they know how to do that function using another program (Via C programming for example)

In a situation like this you must ask yourself are you using the right tools? Since dropping everything and restarting in another tool is rarely a good option, education is usually the better option. There are many training courses for the various authoring tools out there. Many of these courses start with the basics, (As they should.) But with experienced programmers learning a new language, they often get frustrated spending time on the basics that they already know, that they tune out and miss the important lessens. Or they might overlook how the basic stuff applies to the more advanced stuff that they want to learn. This is a common problem that many instuctors face. Make the instructor aware of what you expect to get out of the course. Familiarize the instructor with your understanding of the material so that you don't waste time learning what a cursor is. If it is possible, show the instructor a prototype of your product, or at least give him a general idea of what you are trying to do. This way he can tailor the course to meet your needs. Every class has at least one person who doesn't understand the "big scary electronic typewriter computer-thingy" in front of them. It OK to make this person go get the coffe (often). You'll just be doing their work anyway.

Often a full training class is not a option for many smaller companies, or the course may include many people of various skill levels and customizing the course is not possible. Besides your employees were supposed to have a certain skill level when you hired them.

Since training courses are not always a option, the next option (and more easily accessible) is make sure your people have access to all the resources necessary. Invest in a book on the Authoring tool and get them internet access to get the on-line help files, subject-related chat rooms and other web resources. If they don't know how to do something they can download an example, read how to or even ask other programmers on line. On the internet there are thousands of free resources just waiting to be tapped.

The documentation that comes with the Authoring tools may be comprehensive, but rarely does it explain everything you need. Making sure the programmers have the resources to fall back on will help tremendously. On the authoring tool's web page there are always updates, work-a-rounds and other fixes to problems that have poped up since the software release.

If your programmers are just bitchy by nature.....sorry that's your problem.

Are you using several authoring tools or languages?

Although there are prefectly good reasons to use two or more languages, you have to ask...Why? Is there a limitation of the authoring tool that you are using or is it a limitation of skill. Many authoring programs can do things like read and write data files, play media or launch other programs. So why launch a director application from a Toolbook program, if the Toolbook application can do what the Director program can do? Often DLLs (Small helper programs usually written in C/C+ code) are used to enhance the program's ablity. This can be good or it can be bad.

If the tool can do the job let it. That way if your program goes heywire, you have support from the manufacturer of the authoring tool to help you fix it. If you use your own sub programs, you are totally on your own if it goes screwy.

DLLs can be very helpful if you are trying to expand your program's ability. (Such as playing a new type of media) But they can be harmful, if your program is so dependant on DLLs that you are not sure if built in functions will work. (Yes I've seen this happen) I'm not saying DLLs are bad, just use with care.

One thing I should mention, there are some losers out there that will hide faulty code, so that they will be hired back to make a 2.0 release. They usually are the only ones who have the source code to fix it. Whenever you hire someone, make sure there is an editable copy of the code (and paper copy) as backup before the product is released. This way if you are unfortunate enough to deal with one of these people you will at least have the option of hiring someone else to fix it.

You are Visitor No:

Designed by: Jim Kieran

Graphic by: Zyworld & Xoom