Incompatibility breeds complexity

Many years ago before single-page applications were commonplace, I was building a web app with a few other engineers.

Our tech lead decided to roll our own custom validation framework.

For integrity reasons, he wanted validation to happen in the domain model. Values rejected by domain-level validators would be re-displayed in the web UI.

This worked well enough for the most part. Until we had to do this:

Requirement: if date or time is invalid, reject

You might wonder “What’s so hard about this?"

To which I’ll say “Right?! It should have been trivial!”

But it wasn’t. What should have been a 10-minute job exploded into a serious time sink.

Over the span of 6 months, it kept coming back repeatedly in the form of a bug. Our fix kept spawning a new bug.

It was infuriating!

Why did this happen?

Here’s a diagram to help you see the picture better:

One timestamp field in the backend, but two UI fields in the frontend

Can you spot the problem?

Two kinds of incompatibility lurk inside this seemingly innocent architecture: field count mismatch, and logic placement mismatch.

We had one domain model value to be validated, but two UI fields for error display. The validator, living blissfully in the domain layer unconcerned with UI, would happily reject a single bad timestamp. But the UI layer, upon receiving this single error, had no idea what to do with it. Is the error message for the first field or second? Or both?

We had to write stupidly complex adaptors to bridge these 2 mismatches.

This experience affected me so much that I came up with my own adage: incompatibility breeds complexity.

Through many years of observation I see that it applies to engineering problems, people problems, business problems - everything.

As you see in this post, Shape Up’s concept of appetite removes a common incompatibility that trips up most of us.