Question

While developing products, we often need to create proprietary tools to test some of their unique features or diagnose problems. In fact the tools can be at lest as interesting as the products themselves, and some of our internal groups have asked for copies of them.

So, aside from the obvious business-driven rules (e.g. don’t retrieve sensitive data), what do you differently when you build personal or internal tools, as opposed to for-sale products, and why?

What’s more (or less) important to you in internal tools, and do you consider overall value to the company when you build them?

Thanks for your thoughts!

Answer 1

1. First, internal tools are always developed quick and dirty. Almost no testing – it just has to do the work.
2. UI is not as important as with a customer-facing app.
3. Internal tool can use internal/private/proprietary knowledge of the products and frameworks they test. For example, our last product bypassed part of our published API and used a non-documented web service call to achieve better results.
4. This is an important point,but a losing battle: NEVER EVER leave internal tools with a customer. As a consultant, I sometimes had to use and even develop those tools in the field. I try to hide it from my clients, but from time to time, they demand I leave the tool with them (or worse, call the sales rep and ask for that ‘magic tool’). You don’t want customers judging your entire company’s production level based on tools build according to points 1-3.