What Einstein might have said about "Going Back To Baseline"

[SaschaWildgrube]

“Insanity is doing the same thing over and over again and expecting different results.”

 Albert Einstein

Many have tried to solve problems by “going back to baseline”. Many observations indeed may lead to the conclusion that going back to baseline may be a good idea.

Do some of these observations sound familiar?

• The performance of the instance gets worse and worse
• The pace at which new requirements are implemented and rolled out slows down
• Adoption of new platform capabilities slows down or is prevented because no one can make sense of the “skipped records” any more and new platform features require updating OOTB records that have been customized
• Each roll-out produces more and more regression defects
• The team complains about “too many customizations” which are difficult to handle and no one really knows how the different pieces work together

It appears straight forward to blame the sheer amount of customizations as the root cause of the situation. And it is more than tempting to conclude that starting all over again with a clean slate would fix the situation.

The situation may sound familiar and you may even have participated in a back to baseline project in the past.

If that is the case, the following aspects should sound familiar, too:

• Initially everyone agreed that going back to baseline is a good idea, but once process stakeholders realized that this implies changing their processes, they opposed or even derailed the project
• Not understanding the existing customizations in the first place led to uninformed and sometimes problematic decisions on what to transfer on the greenfield instance and what to throw away
• After the conclusion of the greenfield project the instance experienced heavy customizations again after a few years

Let us face the ugly truth: The idea of solving problems by going back to baseline is a myth.

And Einstein might have said: I told you so.

The root cause of these observations is not the customization itself, nor their complexity, nor their amount. Hence the solution to the problem cannot be to wash them away.

Going back to baseline may conceal the underlying problem for a while before the same observations will re-surface. And all of that at a terrible cost: Going back to baseline projects are expensive – mainly due to the implicit process re-engineering that they imply – which is often not anticipated while planning.

Following Einstein’s insight, going back to baseline is downright insane – if the process remains the same. The solution to the problem is to fix the process.

This is what the "CICD whitepaper" is all about:

https://www.wildgrube.com/download/A%20mature%20Development%20and%20Deployment%20Process.pdf