Category: Anti-Pattern

An Anti Pattern when using Continuous Integration & Automated Tests

Anti-Pattern Testing 2 Comments

The Setting

Once in a while I meet teams who are using a Continuous Integration (CI) system, for their builds and executing the unit tests (yes, there are still teams using a CI for building the software, but not executing automated tests [or checks]). So this is the setting:

  • There is a CI system.
  • There may be unit tests being automatically executed either after check ins into the version control system or at least nightly.
  • In some cases there are failing tests (or checks).
  • Broken builds are displayed on the start page of the CI system in the (intra) net, but not ‘radiated’ so everyone can and will see them.
In this post I focus especially on the cases where the last two points are true.

The Observation

I think this is problematic at least, likely also dangerous, because when there are failing tests and/or broken builds  for some time the team will very likely develop features base on broken software. Getting back to a clean and working system gets harder and harder as time goes on.

The Aftermath

A change in the behavior of the automated check can go unnoticed: Since no one watches the first test fail, it’s unlikely that someone will realize that other checks start failing, too. Furthermore new features might depend on the brokenness somewhere else.

Now What?

Do not live with ‘broken windows‘ & apply a ‘Stop the Line‘ (or check out what Google says about Stop the Line) policy: As soon (read: right after it’s discovered) as a problem becomes known, solve it and then continue with other work. Like everything else, this is supposed to be done by the whole team. When everyone helps, things get solved quickly.

A leaving thought

In my opinion, introducing a Continuous Integration System and then ignoring the results is certainly a major anti pattern, that can do more harm than good for the development process. The effort of setting it up and keep running and then ignoring the information it provides is a form of waste. Is it possible that in such a case you’re better off not having a CI system? Honestly, I’m not sure.

Note however, that I am in strong favour of…

  • having a CI system,
  • actually using it to build the systems and execute automated checks against it,
  • radiating the results to the team and
  • acting upon those results.

The Opposite of ‘More of Something’ Is Not Less of It

Anti-Pattern Pattern 5 Comments

One pattern I see often is that people (me included) apply more of some X, if applying the usual amount doesn’t yield the desired result (anymore).
Two examples from very unrelated fields:

  1. If a dog or other pet doesn’t react in the desired way to a command (‘sit’, ‘down’…), many people start shouting at the dog again and again, which may or may not work at first, but will also fail eventually. Stopping to shout at the poor dog won’t solve the problem either.
  2. In software development I’ve seen rules and policies added to a given process again and again. In these cases the goal was to make the teams produce better products faster (and probably more predictable). That doesn’t lead to the desired results either. But reducing the number of rules is not enough to get teams out of trouble.

So when X doesn’t work, or doesn’t work anymore, applying more of it won’t help. Alas reducing it (less/no shouting at the pet, removing process load from projects) won’t solve the issue.

It seems to be a lot more promising to try an entirely different approach. After realising issues with waterfall projects, we (as software developers) found agile methods to be helpful. In the case of training a dog it’s another way to help the dog learn a new command. In some cases it may even be necessary to teach it its name before.

Did you see anything like this? Let me know.

© 2012-2023 Stephan Kämper — Mastodon

MENU

Navigation

%d