Assessment is for evolving systems, not for legacy ones

One idea I hear recurrently is that assessment is for legacy systems. In other words, if you do not work on a legacy system, you do not need anything assessment related.

By legacy systems people understand old systems that are hard to understand, and that still have to be continued being developed. This can be a reasonable description of a legacy system, but there is still the open issue related to the meaning of "old". How old should old be to be old? 15 years? 10 years? 5 years?

How about a system built by 10 people for a year? Is that not legacy? Of course, it is.

My practical definition for a legacy system goes like:

A system that is still worth to be developed, and that does not fit reliably in the team's collective brain.
Tudor Girba

Time is not a useful criteria to define a legacy system by. It does not matter how old the system is as long as it can be dealt with cheaply. A better way to judge the legacy by the level of system's size and complication (I am not using the complex word to not confuse complexity theorists).

The larger and more complicated a system is, the more it does not fit reliably in the team's brain. I stress the reliability aspect because most often you might feel as if you are in charge, while in practice you are not. When the system comes with too many details, you simply cannot manage it all with only your brain, even if it's a collective brain. You need better techniques to make sense of the system's internals and estimate the evolution impact.

That is what assessment is for.