Waiting for King Sebastian

This is a disordered world that is difficult to explain easily or rationally. An engineer at their root is someone who tries to demonstrate their understanding of it with code. Engineers will sometimes place their faith in a singular technology, framework or solution that has no place for the systems they are developing. We pursue this messianic idea at the cost of everything else. Cynics among us describe this as “resume driven development” but truth be told I am not much of a cynic and I think we are driven by something far deeper.

King Sebastian was the king of Portugal from 1557 – 1578 and died at the Battle of Alcácer Quibir. This was a disastrous military defeat which led to the state being almost bankrupted. All evidence pointed to him having died in battle but the people could not believe it and a legend grew that he would one day return and save the nation. This idea became known as Sebastianism.

We wait and watch as our best laid plans turn to bugs, trigger alerts and our complex systems become increasingly difficult to manage while we lie in wait for King Sebastian to return. The whispers begin, they turn to mumours, slowly we begin to see blog posts that promise to solve the problems we are experiencing, soon they end up on the conference circuit and then before you know it every developer and their dog is now claiming that it holds the key to solving our problems.

Some of the worst examples of Sebastianism I have seen in organisations is a business with 20 or so development teams that adopted the Spotify model to address their perceived lack of velocity. Management was convinced that increased autonomy would lead to faster delivery but it was a disaster. Progress on the delivery of features stalled as teams became completely focussed on how they delivered rather than business outcomes.

An organisation adopted 3 different database engines in 3 years. Each time they were convinced that it would solve all of their scaling issues and each time they embarked on a costly organisation wide migration only to find the scaling issues reoccurred regardless of what their eventual persistence layer was.

In one business having come to the realisation that immutable infrastructure was the answer to all questions, they rebuilt their monitoring platform that was not cloud native. The organisation was convinced it would solve all of configuration and scaling woes however due to the platform primarily being configured via a UI it was a disaster and it made configuration drift inevitable.

Is delivery slowing down? Are you noticing a degradation in performance or customers impacted in some other way? Chances are that you can solve a lot of your problems with surgical identification of the bottlenecks and focussed work to improve them without necessarily wholesale change of your systems.

Be suspicious of the need for rewrites, decisions presented as binary options or advocations for wholesale change in order to address specific technical problems. They are praying for King Sebastian's return. Be grounded and prioritise incremental change.