Clever Geek Handbook

Guidelines for special tools

When 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 as interesting as the products themselves and have been asked by some of our internal teams to copy them.

So, aside from the obvious business-driven rules (for example, don't retrieve sensitive data), what do you do differently when you create personal or internal tools as opposed to products to sell, and why?

What is more (or less) important to you about internal tools, and do you consider the overall value to the company when creating them?

Thanks for your thoughts!

+1


source to share


4 answers


  • First, internal tools are always quick and dirty. There is little to no testing - it just has to get the job done.
  • The user interface is not as important as when using the client application.
  • An internal tool can leverage internal / proprietary / proprietary knowledge of the products and platforms they are testing. For example, our latest product bypassed some of our published API and used an undocumented web service call to achieve better results.
  • This is an important point, but a losing battle: NEVER EVER leave internal tools with a client. As a consultant, I have sometimes had to use and even develop these tools in the field. I try to hide it from my clients, but from time to time they demand that I leave the tool with them (or worse, call the sales person and ask for this "magic tool"). You do not want customers to judge your company's entire production level based on creating tools in accordance with points 1-3.


+2


source


From a technical point of view, I wouldn't do anything differently:

  • Both internal and sales tools should be well written and well documented.
  • Both must be created with a set of requirements, timelines, budget constraints, etc.
  • Both must be tested or verified.


One big difference I see applies to products to sell, not internal tools: selling products requires marketing, support, etc. that internal tools can do without.

In addition, since the internal tools will be used in a slightly more controlled environment, they do not need to be tested on different computer systems, internet browsers, etc.

+1


source


The biggest difference:

It is with personal and internal tools that you can be more free to experience new technology, latest fashion. You can run the risk of not accepting with the app you actually ship to customers.

+1


source


Since the diagnostics I build are usually very purposeful, I tend to provide more options and built-in examples than I do for customer-centric products. In other words, I am assuming that the user is more familiar with the technology than the client is usually, and I provide more options for customizing the way the tool works without worrying about overwhelming the user. But I also try to make it satisfy 80% of use cases without much "help" from the user.

0


source






More articles:


All Articles