So this is my first post under what I like to think of as my â€œhelp us help youâ€? section of the Blog. A lot of times users contact us at the tail end of a project sweating and fearful of not meeting their deadline praying we can work a miracle. Hate to spoil your hopes and dreams here but the number cases we can work a miracle on a short deadline are few and far between. We have a saying in Supportâ€¦ â€œtest early- test oftenâ€?. You have to keep a few things in mind before you seek assistance and ask yourself a few questions to help set your expectations. This is the firstâ€¦
• Is you code centralized and documented with comments?
If you think undocumented code scattered across dozens of movie clips and nested in dozens of SWFs is hard for you to read and keep track of, it is virtually impossible for someone to follow it who has never seen it before. The scope of support regarding troubling shooting code is very narrow. Technically, if the support engineer can’t determine that a feature is not working as designed, then they are not in a position to open a bug or develop a workaround to the problem. If the problem in your application can not be isolated due to its complexity, the help you are going to need will be closer to consulting then support and well that is just another service all together. (Oh and that service is not free of charge.)
• Always use best practices when building your applications (its good for you, its good for your support experience; its good for health and wellness by lowering the stress of all who must look at your code *grin*)
• Always provide a wealth of comments that describe what each method and function is for and when possible how it works and how it relates to the rest of the application (I can’t tell you how many times I have heard a user say, â€œI forget what this doesâ€? or â€œI’m not sure how this works but here is what happensâ€?. Big projects can put a strain on memory, that’s what the comments are for; use them.)
• Be prepared to walk the support engineer through the logic of the entire application (By the way, if you find yourself having difficultly explaining how your application works, you should probably consider that design is too complex, and accept the possibility that if you don’t understand what is working, you can’t hope to figure out what is not working in a brief amount of time.)
A B & C are key to a good a experience with your support engineer. Remember, if you have not encountered a known bug with a known work around, it can take some time to get to the root of your problem. Clean easy to follow code, and a good explanation of the application logic and design can help the first level of support quickly identify you as an experienced developer. It will help the engineer to quickly rule out likely and common causes for the problem and get your incident escalated to the next level of support quickly and in most cases will let the next level of support start where the previous engineer left off and not from the beginning because of a need to verify the known(s) and unknowns of the issue.
I hope that helps your next support experience.
I welcome any comments on your experiences with Macromedia or other companies’ technical support departments.