Every once in a while, computer scientists come up with a new architectural model that inspires developers to build better software which has the potential to reflect positively on each respective business.

Throughout my career, however, I have observed an architectural model that seems to form itself within organizations when there is a complete lack of or small degree of discipline surrounding standard software architectures. I like to call this the “Savior Architectual Model” – or Sam for short.

The savior model is simply the kind of architecture that is so convoluted and complex that only its maker can understand it, hereby known as the savior!

For others to be able to modify, or even attempt to improve upon this software they must consult the savior and get his or her blessing before contributing to the code in order to get any tasks done.

So when things do go wrong, only this proverbial savior can save the day and hence, get the usual praise for “making it work”.

Saviors come in all different shapes and colors.

Some are just grumpy, some may hate their jobs, some are neurotic, some may be clinically depressed and some others just don’t like people.

But it seems it’s always your fault if you don’t know how to communicate with them!

Forget about your computer science degree. Who needs that? You must have a psychology degree to be able to get some sense of “documentation” (heh, what’s that?!) or be able to write a single line of code without being bombarded by criticisms from the savior’s followers.

You must make sure your code change has a comment that says: “I have been blessed by the savior!” in order for their followers to leave you alone and allow you to “innovate”.

The savior model happens when organizations don’t stress the importance of involving multiple parties in the design and decision-making process.

It also happens when organizations loosen up on documenting how any critical software is being built, and what architectural standards are being followed to develop the software.

Especially the second part, as software teams change all the time, you might end up with one person on a team who happened to be there when all the “magic” happened. And that’s how saviors are born!

Outdated architectures, like in the monolithic applications, are a good example to inspire creating all kinds of saviors.

When the code base is tremendously huge, and there are few or non-existing tests in addition to the lack of documentation, saviors start to creep into the organizational structure and slowly they become a bottleneck in the production process.

As teams grow around a monolithic application, so grows the number of requests to submit new features or fix defects which requires more questions and more understanding of how the system was built to follow some sort of “pattern”.

And here comes the issue of having to return to the savior to answer all these questions and explain how the mysterious software works.

This adds to the other bigger problem in which your software is running into issues and only the savior knows how to solve them. Now imagine if that happens on your savior’s vacation day? Maybe at midnight? While they are being hit by a bus?

Your software comes to a halt and you lose more money than what you would’ve spent enforcing documentation, education and ownership across the entire development team.

Software development teams need to press very hard on few things to avoid falling into the savior model:

• Follow global architecture standards so newcomers to your team are easily familiarized with the system and are able to go search the web and read books about what standard the system design follows so they can contribute with knowledge and not break your software.
• Stress the immense importance of documentation and rotate tech leveling sessions to continually discuss and educate your team about how the software works and engage them in the design process to create a sense of ownership and pride in the software they’re building.
• Unit test, acceptance test, integration test and system test your software. If your software is tested properly with high code coverage, it’s very likely that engineers will figure out somehow what the code is meant to do without having to ask too many questions.
• Adapt a new architecture pattern like the Microservices architecture to reflect your organization communication structure and distribute ownership across teams and team members. Smaller code base and smaller teams inspire ownership.
• Rotate development tasks on the development team members. Don’t have a “go-to” guy for doing a specific task, that’s how you create mini-saviors that eventually turn into saviors that slow down and silo and tribalize your software.

At the end of the day, allowing the savior model to creep into development teams gives too much power to one member – the “savior” and leaves the rest of the team in a prison of thought that doesn’t give them much room to innovate and have a counter equal input in the design process of the software and leaves them intellectually paralyzed which should inevitably negatively affect the overall performance of the organization and the software being written.

And if you think giving one person too much power to make decisions doesn’t necessarily corrupt them check out the Stanford prison experiment.