Any time you have complex systems you can wind up with some strange interactions between different parts of code.

I ran into an issue like this today.

The system I’m working on had some features I was working on. I committed them yesterday when things were working just fine.

I get a frantic email this morning that I broke someone’s build. For code that they hadn’t yet committed.

:-/

It’s hard to fix something that you can’t see.

It’s especially hard when a build can take the better part of an hour to get to the point where the newly committed code can be seen to cause problems.

Which gets me to the antipattern. A large chunk of our system is based on hibernate. This by itself isn’t shocking (and leads to another rant that I’ll save for later). Hibernate takes a configuration that describes the data and database you’re trying to access and then generates a buttload of code. Generated code doesn’t need unit tests. You test the generator then by induction the code it generates is fine. If you don’t trust the generator then you need to fix that problem.

Most of the build time is running those unit tests.