If a concept in your software is not actually represented in your code, does it really exist?

As a simplistic example, if your customer or user thinks of your application in terms of "notes", but there is no code that describes anything called a "note", that concept is not represented in your code.  One significant thing an agile development team can do to make a code base more agile (supple) is to ensure that there is a high degree of correlation between how we describe and think of our software, and how it is implemented.

This is another way of looking at Ubiquitous Language, a fundamental concept of Domain Driven Design.  Oversimplified, the nouns and verbs of your system need to be aligned with the nouns and verbs used to talk about the system.  But even more essential is the alignment of concepts: words may need to be translated, but it is infinitely more complex to reconcile disparate concepts.

Why is this important?  For one thing, aligning the implementation with the picture in the customers' heads reduces a lot of friction in communication while developing features.  Additionally, a system that doesn't reflect the mental model that bore it will eventually prove rigid and resistant to new features to: the customer may want something that, while perfectly compatible with his idea of what the system does, is impossible to implement.

When a concept changes dramatically for the sake of a feature (e.g. a major change or addition), we expect it will be a large effort.  However, if the concept doesn't change much, but the code does, it's an indication of a departure in the code from the concept.

How does this happen?  Basically, the developer conceives different abstractions than the customer, and these are never resolved.  This can be caused by poor communication, insufficient design or premature generalization.  Most often, we are driven as engineers to provide value by 'translating' the customers needs into implementation instead of fostering and maintaining a ubiquitous language.

Then, down the road, when the customer expects to extend or enhance a concept that's poorly represented, there are no cohesive parts in the code to target.  As a result, the developers find themselves doing "shotgun surgery" all over the application to try to get the application to behave as the customer expected.

The value we provide between concept and delivery is not a one-way translation: it's a dialog.  Moreover, the apparent simplicity of this idiom should not cause us to pass it over for more complex and seemingly sophisticated solutions.