I’ve been through Agile training several times before at different jobs, and the current job is no different. June is Agile Training Month, and since I started last September I’m obliged to go through this again. Previously, we had a Clean Code Training period that lasted two months, and I realized today why I’m having such a hard time with the Clean Code part of the training.

The Agile process says that the product should have value to the customer at the end of the first month, and that the value to the customer grows as the development team puts more intellectual work into building out its functionality.

In Agile Training, there’s a popular metaphor of “building a personal transportation system.” The story goes that in the days before Agile (and before Clean) a team would figure out what a fully realized personal transportation system was, then build that final product: an automobile. Once the automobile was designed, they’d build a frame in the first week, add tires and a steering wheel in the second, then the motor, then the cabin, and so on, until at the end they delivered a fully functional automobile.

Agile points out that in all that time it’s taken you to build the automobile the customer hasn’t been able to go anywhere. The customer gets no value. So Agile starts by building a two-wheeled scooter in the first week, then refining the scooter with a bigger frame to become a skateboard, then even bigger to a golf cart, and eventually to a fully realized automobile. At every step of the way, the customer can go somewhere, if at first awkwardly, slowly, and without protection from the elements.

Agile further argues that since the built the car iteratively, with forethought about future recombination, the team has built a componentized system in which parts can be swapped in and out without too much pain. Agile advertises that if your customer changes platforms, databases, operating systems, or display mechanisms, you should be able to adapt to those changes quickly because of the componentized nature of your system.

Clean, in contrast, focuses on a single component of the system: the programming language. And not just any programming language: Clean focuses on noun-oriented programming. Everything else is somewhat secondary.

Both systems claim that their way is best, and that if you adopt one your code will be flexible and adaptable to the realities of the modern world. Agile encompasses everything, but Clean only looks at the program written in the programming language, and more importantly, Clean says that that programming language cannot be changed, not without great pain to the developers and the customers, which is why everything else must be mocked.

Most data is related to other data, which is why the relational data model is the most popular model, and the databases that support it, such as Postgres and MySql, are among the most battle-tested pieces of software in the world.

A mocked backing store can’t deliver customer value.

Delivering the prototype with a hand-written relational data engine is professional malpractice akin to delivering a prototype in a programming language the team wrote in-house, in assembly language, for a CPU nobody has used in twenty years, without any documentation.

In the end, there are only two units of “value” in the system: the abstract future-proof value of the UML that describes the system in a complete end-to-end format, with accurate descriptions of the protocol individual units of the system rely on, and the real-world value of a product the customer is using. If your choice of language constrains your delivering value, use another language.