Many developer support cases deal with problems that simply do not
occur in code generated by the IDE. In these situations, it is very
helpful to the engineer working on your case to have a small example
that demonstrates the problem so they can do testing on their end. Having
the engineer work out their own example of the problem takes more time
which means a delayed solution. Also, not knowing exactly what to send
to your engineer can lead to a lot of back-and-forth exchanges which
can further delay the resolution. What follows is a list of suggestions
to help you provide a good example of the issue to your engineer.
- Make sure your example is complete in itself: An incomplete example
will only make the case take longer. For instance, an example of your run-time
database connectivity failure which doesn't compile due to missing
auxilliary files. Be sure to either include the necessary files to
get the example to run or remove the references to unnecessary files
before sending it to the engineer. Test it before you send it to make
sure it functions in illustrating the errant behavior.
- Make the example atomic: That is to say, make it so that it cannot
be reduced to something simpler.
The example should only include source code and
libraries related to the issue. This may require you to rework your
code before sending it but your case will go faster this way.
- Try to make it generic: Examples that are dependant on specific third-party
software are much harder to deal with.
Borland Developer Support does
not have every permutation of database, application server, utility
component set and operating system available to them for testing. Everywhere
you can, remove third-party components and use the database or app server
that came bundled with the IDE. It is understandable that sometimes this
is not possible, but doing this when you can will speed up the resolution
of your issue considerably.
- Make the example a complete project: An example that can be opened as
a normal IDE project is always preferable to an unmanaged heap of source
code. Most of our products use a "project" abstraction as a way of managing
not only source code, but also auxilliary libraries and build options.
Sending a complete project is like sending a road map of your application.
- Send it in the structure it appears in on your drive: Meaning once you
have created an example that demonstrates the problem, the whole problem
and nothing but the problem, zip it up right there and send the whole thing,
folders and all. This will help eliminate time spent recreating your machine's
directory structure and time spent hunting down missing files.
Following these guidelines will give your engineer the tools needed to
solve the case quickly. More importantly, they will be happy!
|