Building Evolutionary Architectures: are fitness functions just tests?

Is a fitness function just a test by another name? Building Evolutionary Architectures by Neal Ford, Rebecca Parsons, Patrick Kua, and Pramod Sadalage revolves around this single term. The 2nd edition (2022) is subtitled Automated Software Governance. The book defines a fitness function as something that “provides an objective integrity assessment of some architectural characteristic(s).” A skeptical view might be that this is just testing, repackaged for consultants. The book kind of agrees.. it says that a fitness function can be a unit test, a metric or a monitor.

The difference is what the check is aimed at. In a Thoughtworks podcast episode on architecture as code, Ford describes them as unit-test-like checks aimed at architecture. He says most aren’t written in the application’s language, but instead are usually a pipeline job or a production alert. For example, you might have a build that fails when two packages create a dependency cycle. That’s not usually written as a behavior test (no user will ever notice the cycle, but the architecture will notice it a year later when you can’t change the packages separately). I think the “these are just tests” people are right about how it works, but wrong about what it’s doing. The check itself isn’t new, but what it’s checking is.

Every pull request to my site has to score at least 90 on Lighthouse in every category. That’s a fitness function in all but name.. and I think the name earns its keep. If a characteristic has a name, it has a threshold. If it has a threshold, it can fail the build. If it only exists as a principle, it has no threshold, you argue about it in a review meeting, and you don’t check it on every change. What characteristic in your system is only checked in someone’s head?