I have built and operated software development platforms in multiple industries for over two decades. A 1:1 discussion inspired this blog post.

Software development platforms allow product development teams to deliver features in less time, with high security, reliability, performance, and built in compliance. Unfortunately, in the long haul, this turns out to be a two edged sword. As these platforms age, they tend to become monolithic (more code, less modular), and more complex (offering too many configuration options, feature flags). Replacing aging platforms is hard and error prone. There are many heroic blog posts on the internet where engineering talented teams discuss their struggles of migrating from existing to new platforms.

A talented software development organization as a startup engineered a wildly successful platform, and as both customer count, and feature asks grow, then over time:

  1. Code bloat tends to accumulate in the platform. This is because in the short run, it is cheaper to add new feature specific code inside of the platform (maybe with a feature flag) instead of implementing it fresh by the product development team.

  2. Shift of focus from solving customer pain to performing platform enhancements and changes. Since the platform code is by definition more generic, it is more involved to make changes, and there are only a handful of experts who can confidently make and or guide useful changes.

  3. Troubleshooting issues becomes harder, and problems are involved. Given the above situation, hapless product teams build abstraction layers to interface with the platform. Since the platform supports multiple, diverse use cases, it is harder to configure correctly and debug when things don’t work as they are supposed to.

There are other symptoms that I could call out, like the rise of tiger teams, quality and release issues, and unhappy customers with slow pace of feature delivery, but these all stem from the three points I enumerate above.

Software development platform usage and dependence should be made optional by product development teams.

This is a controversial and counter intuitive stance to take for many engineering leaders and senior engineers. In the short term, it will be wasteful and more costly. However, I argue that development platforms should be only solving for small targeted core capabilities, and nothing more.

This means that additional useful capabilities have to be addressed and implemented by product development teams. Moreover, if a product development team so chooses, they can even develop and maintain a subset or even entirety of core platform capabilities. The benefits of this policy immediately follow:

  1. No bottlenecks on the platform teams for product feature development. This in turn can mean more thought and effort can be spent on testing, reliability, security, and performance.

  2. Platform code base is a small core, and can be replaced and or evolved in a more measured manner as and when technology inevitably changes.

In a later blog post, I will discuss organization concerns, and how we can attempt to migrate existing aging platforms to this way of working.