The Data Studio

Artefacts

Not long ago there were just two definitions of an artefact:

One was: something found by historians; something made or used by an ancient human society, something that tells us about the way they lived. This is very positive; such artefacts help us to build a fuller picture of our origins.

The other definition was: something that interfered with a scientific experiment - a result caused by the equipment or by some kind of contamination. This is an artefact with a negative consequence; it misleads our understanding of the thing we are investigating.

Now, we have a new meaning for the word “artefact”. It is used for anything that can masquerade as the product of an application development process: code, diagrams, plans, notes, charts, configuration files, and so on. We have so many artefacts now that there are products just to manage them.

When the “artefacts” are actual code files that can be executed to implement a useful part of the application, then it is good that they exist and good that they are managed.

However, when “artefacts” have their status elevated by being managed in an artefact management tool then there is a real danger that we start to see them as valuable in themselves.

It is generally much easier to produce the sort of artefact that cannot be tested and is of no use to anyone. When your manager says “what did you achieve last week?” you can point to the artefact repository as evidence of work done. But if that work was pointless or unverifiable then you should be ashamed of yourself. We are not here to produce diagrams or XML files. If these things actually help to deliver something that works for our users then they are worthwhile; if not, then they represent wasted time.

Too often “artefacts” are just busy-work and distract from the real stuff we are supposed to be doing. A classic example I endured was the “canonical data model” that a large finance company spent millions of pounds developing and never used.

Scrum can be a good framework for agile development projects. But it has become so widely used that many companies have tried to grab a piece of the action by adding tools around Scrum. Very often these tools move the focus from actual development of applications to the creation of more and more artefacts. Big companies favour such tools because of the artefacts that give an illusion of progress. This allows them to continue with their old bad habits of doing stuff for which they can never be accountable: so they can say they have put in effort and no-one can ever complain that it doesn’t work, because it doesn’t do anything and cannot be tested.

In such organisations, what they call Scrum is often the opposite of what the Agile Development pioneers envisaged. It is a way of doing piles of useless busy-work. These organisations give Agile Development, and Scrum, a bad name.

I don’t use artefact management systems. I do use version control systems (preferably Subversion) to hold every executable file, and the tests that find out if they don’t work, and any documentation file that will actually be used by someone enhancing, fixing or running the code.

If an “artefact” does not contribute to the successful operation of the application, then I don’t want to waste time creating it, storing it or managing it.

Agile Development is a wonderful innovation, improving the experience of developers and users, but only when it sticks to the goals that the originators of the Agile Manifesto formulated. Dave Thomas famously says that “Agile is Dead”. In many organisations that is, sadly, true.

If you are more occupied with collecting and filing artefacts than you are with meeting the changing needs of your users, then you have blown it. If you haven’t even spoken to your users in the last week then you should look carefully at yourself and if you just don’t want to talk to your users then you should look for another job, in a different field.

Whatever framework we use, we must keep the focus on delivery of working code. And we should be getting frequent feedback from our users to understand if we have met their needs, or not.