Your stack is only there to make your job a breeze.

When picking an application stack, my goal is to make delivering the best user experience pleasant for the developer. I’m a developer. I want to do as little work as possible; not (only) because I’m lazy, but because if I can easily provide something new and useful for a user, then my tools must be suited for the job.

I’d often model backend app state as a graph of resources with a REST interface. I would lean on REST to the furthest extent possible. The nice thing about resourceful REST is that it imposes a discipline that restricts how you can model queries and mutations in a service.

The biggest shame is when a team implements some discipline, and then at some point decides that– for some “special” feature to be delivered –they need to slightly break the discipline.

The problem with breaking the discipline is that the team took a previously simple model used by all developers who work against the stack, and introduced an exception. Now everyone needs to be aware of the nature of this exception so that they can work around it. Now workflows need to be altered. Now developers need to work slightly harder to achieve something of ordinary value.

At the time that one exception was introduced, it was considered a “special” case… but if the team was willing to break the discipline once, it’s unlikely that there will only be one special case in the lifetime of the stack. Here’s the problem– separate pieces of an application, while perhaps logically or even physically independent, will eventually be integrated by some consumer. The consumer that integrates the exception, implements it specially (as required)… so artifacts of whatever discipline-violating attributes it has are hard-coded in now a second place in the stack. This effect is compounded with each exception that’s added.

After the stack evolves a bit, nothing makes sense anymore. Everything needs special documentation, and intuition isn’t useful because there’s no common pattern. Based on the team’s demonstration of how it values discipline, it’s likely much of the documentation it relies on will go on unmaintained. There will be a small group of developers on the team whom everyone asks for help. The time between when a new developer is hired and when they become effective is long.

If your team reaches this state, you will need to fix the discipline problem before you can ship the great features you envision. Otherwise there’s no way you’ll pull them off with the quality your (uniquely loyal) users deserve.

Here’s your job: Get the stack right. Stay disciplined. Make your developers happy. Ship work your users deserve. If you don’t, someone else with better discipline will.