Why Cloud Projects Fail

I talk to teams on a daily basis that explain to me that their solution is different. The normal rules don't apply to them because they are uniquely complex and have a unique set of problems that makes their cloud deployment a different challenge. To me this is a huge red flag. While I would argue that yes, every program is different, what makes them fail is strikingly the same and it always leads back to a team thinking that the laws of software don't apply to them.

In my day to day job I work with failing programs; programs having significant technical delivery issues that are making their platforms unstable and anything but cost effective. These programs serve different industries, use different technologies, and have different team structures, but they all have a few things in common.

Fundamentally, each of these programs has made the choice either explicitly or through inaction to not implement more than their most basic non-functional requirements. Each program has made these choices because their funding model didn't include anything but functional delivery; because timelines were squeezed; or because requirements changed and something had to be sacrificed to make a delivery date.

In all fairness, some teams I work with don't consciously make this choice. They honestly don't know any better. Last week I talked to a team that genuinely didn't know how to branch their code in a way that prevented untested features from being deployed in production. This is a different problem. It is no less serious, but it is different.

However you get there though, I'm here to tell you that sacrificing the implementation of non-functional requirements never ends well.

Never.

I have worked with teams that have turned off their unit tests to accelerate development. I have worked with teams that saw logging as an added and unnecessary expense. I have worked with teams that ran performance testing for the first time days before a major go-live. I could go on.

What all of these teams had in common was a willingness to sacrifice strategic long term gain for a tactical win. They choose instant gratification over the actions that will make them successful over the long term and then are shocked when things start to fall apart. This strategy doesn't work with your life and it doesn't work with your software.

To be successful, at the very minimum a cloud software deployment needs:

• Documented, measurable non-functional requirements with achievable performance targets that are granular enough to account for different workflows.

• Consistent, standardised, and aggregated logging and a standard error catalogue.

• Unit testing, code review, and attention to failure and edge cases.

• Failure testing.

• Non-functional testing that includes but is not limited to performance testing that happens early enough to resolve issues before code has to go to production.

• Health Checks.

• Context sensitive dashboards.

• An ongoing refactoring program

There are other items that I would argue should go on this list but these are the ones that I can almost without fail predict will be involved, to some degree, in the slide into chaos that has led me to be called in to a new program.

I read an article a few weeks ago that put forward the suggestion that sometimes, when the path to success seems too complex to tackle, sometimes, it's good enough to just stop failing. I think this is a case like that. The answer to what success looks like on every project is not always the same, but what failure looks like can be predicted with striking regularity. For now, if we want to see the true benefit of moving to cloud, we need to stop doing the things that we know will make us fail. Once we get there, we can make a new path forward.