5 Signs of Managed Platform Entropy

Let’s say your team built an amazing managed platform – one that provides large scale systematic reuse and provides several compelling benefits to your organization and it’s developer community.

You break open the champagne and celebrate right? Not so fast!

Sustaining and evolving the platform requires discipline and persistence. Like any other complex system, entropy will set it and if you don’t get ahead of it, the platform will wither away.

So, what does platform entropy look like and how do we tackle it? Instead of trying to define it, let me suggest a few signs to watch out for:

  • Focus shifts disproportionately from improving a platform’s key functional use cases – i.e. the platform is not constantly improving the manner in which it is addressing the bread-and-butter business problem it was designed for.
  • There isn’t a core group of committers who are constantly monitoring the health and well being of the platform codebase. This includes tracking and fixing nagging bugs, modifying and correcting abstractions, introducing better documentation, making it easy for new developers to understand and extend functionality, etc. If there isn’t anyone obsessing about a sustainable codebase, entropy will win. It is just a matter of time.
  • There isn’t a committed platform road map and releases start to become more and more ad-hoc.  If the platform code base isn’t released in a frequent, easy to execute fashion, don’t be surprised if it gets harder and harder do deploy critical fixes and upgrades!
  • The feedback from existing and potential client developers aren’t acted upon. Are you truly listening to your client developers? are they complaining of onboarding complexities? platform jargon that takes a long time to learn? inability to test their code without jumping through hoops?
  • Not investing effort in making the platform easy to support. Supportability helps with overall platform health in numerous ways – most importantly, drives ability for your clients to self-service their interactions. If support tooling and automation is short-changed, you will spend ever increasing amount of time and effort trying to get the platform to behave in production. If your team is having a tough time differentiating between platform issues vs. issues in the client code, it is time to invest in better and more supportable tooling. Both your teams and clients deserve that investment.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: