1There’s an old saying, “It’s a poor workman who blames his tools.” I’ve always looked at that two ways:
1) A skilled workman keeps his tools well-maintained, so that they work well and can complete the tasks at hand. In software terms, this means that you have a set of development tools that work well, work well together, and you’re skilled in using them.
2) A skilled workman will not tolerate a bad tool. If a carpenter has a hammer with a head that flies off 3 or 4 times a day, he’ll either fix it or replace it. In software terms, this means that if you’re using a development tool that turns out to be a buggy piece of junk, you replace it with something better.
Unfortunately, we don’t always get to pick our tools. Sometimes you come into a project late, and the tools have already been chosen. If you can’t convince the client to get rid of a buggy tool, there are ways to minimize your pain:
1) Map out the tool’s behavior. Figure out what it’s good it, what it’s bad at, and what it always fails at. Use it for what it’s good at, and stay away from the rest. As a hypothetical example, picture an Enterprise Javabeans server implementation that works well enough with stateful and stateless beans, but which has an entity bean implementation that just doesn’t work. If you’re stuck with that server (say, the client has already bought a ton of licenses and it’s too late to get rid of them), you can still build a decent system if you simply stay away from the entity stuff and either use straight JDBC code or a third-party persistence mechanism to do your database access.
2) Supplement the tool with other tools. If the tool has a really bad built-in source code editor, but gives you the option to set up access to an external editor, do it. Even if it doesn’t, you can do most of your editing in another editor and then paste the final version into the tool’s editor. When I was in grad school, I did a lot of development over a 1200 baud acoustic modem. Typing into an editor on a remote shell was just painful. So I’d edit my source file on the PC, then either FTP it to the server or simply paste it into a VI editor window, then compile and run.