Should every target have a secret?

Jul 16, 2008 •

There's a question that I wanted to ask you, dear reader. Consider the following code snippet:

<project name="my_great_web_app">
<!-- snip -->
<target name="backend-zip-static">
<zip zipfile="${build}/backend-static.zip">
<fileset dir="${backend.static.dir}"/>
  </zip>
</target>
</project>

Some of my erstwhile ThoughtWorks colleagues used to use the motto "Every class should have a secret". Recently I discovered that this evolved from work on Information Hiding by David Parnas:

In computer science, the principle of information hiding is the hiding of design decisions in a computer program that are most likely to change, thus protecting other parts of the program from change if the design decision is changed. The protection involves providing a stable interface which shields the remainder of the program from the implementation (the details that are most likely to change).

(from http://en.wikipedia.org/wiki/Information_hiding)

So OO developers believe that classes should contain secrets, should targets in your build have secrets? Does that mean that you shouldn't expose (in the name of the target) how a target does what it does? In this example, how about backend-static-archive as a target name instead of backend-zip-static ?

The example above came from a real project. We changed the way we deployed the app, and had to painstakingly rename the target and its references across a hierarchy of build files. There was definately more than one issue with the build at that project: we shouldn't have had such a large collection of build files. Them's the breaks.

Should you ever expose the process that you apply inside a target? Or should the name of the target just describe the output? What do you think?