On the Use of Tools

[Warning: This is going to be somewhat of a rant] My professional experience now comprises of 18 years (as of 2010) in companies of various sizes and industries.

Regarding the use of tools I found

  • In companies with well educated employees and good practices, the use of tools mostly increases efficiency and, to a lesser degree, quality
  • In companies with not-so-well educated employees and suboptimal practices, the use of tools doesn’t change a thing (other than now a tool is used to produce the same bad results)

And that not really is a surprise.

Example: The creation of use cases. You get good use cases when the creator has thought about

  • What is the goal of the whole thing, the purpose?
  • Who is going to read it (in the sense of “what is their role”)?
  • What information does that person need in order to do their job?”.

That is the education part. It is very helpful, too, when the company provides a standard form for use cases and explains in detail what should go into which section for what reason/ purpose. That could be called process or practice.

This all may sound trivial, but check for yourself: most use cases look like “somebody” had to fill out “some form”, just to get rid of all that empty space.

It gets especially colorful when a number of people have been writing use cases without clear guidance. Each person has their own ideas about what information goes into which section of the form.

Additionally, the level of detail and context provided varies wildly. While some will clue you in that “an order is going to be updated in the database”, the next one will jump straight into the matter and tell you to “change fields foo and bar in table baz”.

Both descriptions might lead to the same implementation, but the latter approach leaves you to reverse engineer the original intention, and robs you of the opportunity to choose a different, possibly better approach to achieve the same result.

  1. To write a good use case you don’t need a tool. Educating your employees will be your best investment, and provide the largest benefit.
  2. The use of a tool will not make a badly written use case better. See point 1. Quality won’t improve just by using a tool. What you can and should expect from a tool: to make your processes more efficient, in example by improving the organization of information you have (better overview, faster access, new views)
  3. It’s easy to write a bad use case with a tool. Again, see points 1 and 2.

You may replace “use case” with “code”, “DB design”, whatever.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>