Hard coding

One of my mentee has recently be assigned to his complete feature.

He started with a conceptual data model (CDM), it would have been great to start with the domain, but, I have realized that we are lacking of a formal way to create schema for Haskell types.

That being say, the CDM was dense, it not only contained the main entities (4 tables), but also a lot of static or nearly static data (9 tables).

Among them, they were the obvious ones, such as the statuses, but also tables for long list of normalized values.

My answer was to hard-code them.

For statuses, they can be converted to sum-types, as follows:

data Status = Draft | Submitted | Accepted | Rejected

In general, these kind of values should be hard coded as they have an impact on the behavior of the system.

Not only they should not be left to the mercy of a database administrator, or a provisioning error, but they have be part of your version control system, type-checker, tests, etc.

Other tables were representing normalized values (from regulations, third-party providers, etc.).

These one could be represented as maps, as follows:

products :: Map.Map ProductId ProductName
products =
  Map.fromList $
    map (bimap ProductId ProductName) [
        (1, "Product 1"),
        (2, "Product 2"),
        (3, "Product 3")
      ]

At this point, my mentee looked at me, full of doubts.

It has the following benefits:

• No infrastructure (no table, no migration, no fixture provisioning, no synchronization issue)
• Versionning
• Auditability
• Simplicity

And these drawbacks:

• The database cannot do integrity check
• A deployment is need when values change
• We need to be careful when removing entries

It might be counter-intuitive, but the correct shortcuts can save days of work, allowing us to allocate more time on immediate concerns, speeding up the feedback loop.