Guidelines for custom tools.

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

From an engineering perspective, I wouldn't do anything differently:

• Both internal and for-sale tools need to be well-written and well-documented
• Both need to be created given a set of requirements, deadlines, budgetary restraints, etc.
• Both need to be tested or validated

The one big difference I see would apply to the for-sale products as opposed to the internal tools: for-sale products need marketing, support, etc that internal tools can do without.

Additionally, since internal tools will be used in a somewhat more controlled environment, they don't need to be tested against different computer systems, Internet browsers, etc.

Answer 2

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.

Answer 3

Since the diagnostics I build are usually very special-purpose, I tend to provide more options and built-in examples than I would for customer-facing products. In other words, I assume the user is more familiar with the technology than a customer would generally be, and I provide more ability to tweak the way the tool operates without worrying that it might overwhelm the user. But I also try to make it satisfy 80% of the use cases without much "help" from the user.

Answer 4

The biggest difference:

It's with the personal and internal tools that you can be more free to try out a new technology, the latest fashion. You can take risks that you wouldn't take with the application that you are actually shipping to customers.