Uniformity

Table of Contents


UNIFORMITY

TTM ROI Sellability Agility Reputation

Uniformity is about identifying commonalities, and leveraging those commonalities to:

One of the toughest challenges for the software industry isn't building the software; it's supporting the people who create it. Every individual is unique. They come with a unique set of skills, experiences, knowledge, beliefs, subjective reasoning, bias, and Rational Ignorance. Whilst this diversity is great for problem solving and Innovation, it can also be an impediment to sustainability - when every solution can be solved in numerous ways, supporting every situation is difficult. Too much (technology) diversification can impede (business) progress.

RADICAL CHANGE OR CONVENTION?

Whilst uniformity is extremely potent when dealing with similar, or conventional tasks, it may lack what's required for radical change and Innovation (which is where unit-level productivity can shine). A balance must be struck within each business - with a mind both on technology and the business (i.e. sufficient context) - to decide when to favour radical change over convention. I talk about this in detail in the Unit-Level Productivity v Business-Level Scale section.

Let me try to illustrate the point. Consider two of Mass Synergy's developers - Jane and Jeff. Jane is a Java developer, experienced in the Customers, Carts, and Users domains. Jeff is a Node.js developer, experienced in the Catalogues and Discounts domains. Each domain is built differently and uses distinct runtime environments.

Let's say there's a sizable new feature needed in the Carts domain that will be very profitable. Jane is already working at full capacity, but even still, it won't be finished on time for the holiday season. Jeff is the only other staff member available to support, but he has neither the technical skills, nor the domain experience. Not only would it take Jeff too long to learn the technologies, he must also learn the domain. In fact, were we to put Jeff on the project, he'd likely slow Jane down, something we can ill afford. There are two opposing forces at play - one relates to (unit-level) productivity (a divergence in technology or practice), the other about business agility and scalability (a convergence in technology or practice).

Uniformity is important, both within software units and within the delivery mechanism. Anyone who's worked with Microservices and/or Continuous Delivery practices probably appreciates this. Uniform deployment pipelines can ensure we get predictable (release) behaviours, every time, regardless of the microservice deployed.

NO FLAIR?

I once worked with a platform that managed all the nuts and bolts for us. There was little opportunity to design anything, and even implementation options were limited (we had lost Optionality).

The platform was marketed as a “saviour” that would greatly simplify engineering. In actuality it hampered any artistic flair (an important consideration), hugely limiting my enjoyment of the role (which also had motivational consequences). A lack of flair can have a knock-on effect on Innovation - innovative solutions are missed that might otherwise be found.

POLYMORPHISM IS UNIFORMITY

What is polymorphism, except a form of uniformity in an object-oriented world? By creating uniformity, we can work with different things in the same way, simplifying understanding and reducing complexity, and therefore, reducing the cost of change.

PILLARS AFFECTED

TTM

If all solutions look and behave (operationally, rather than functionally) the same, there can be little Surprise in their construction, deployment, and operation. This equates to a Known Quantity - where problems and failures have already been experienced and can therefore be easily avoided or rectified. Overall this approach can be used to drive through quicker change, or scale up.

ROI

If different software units have similar qualities, and (generally) behave the same, then we create a suite of software units with Known Quantities. And known quantities exhibit some important characteristics:

This suggests efficiency, promoting a greater ROI. Staff can more quickly adapt to new business needs, with an existing foundation in technologies, practices, and methodologies that isn't radically different to what they're already familiar with.

AGILITY

By limiting technology choice to a (sensible) subset (limit Technology Sprawl), and using familiar deployment and project management techniques, you can easily and swiftly scale up teams in vital areas of your business, or shift staff onto new products with relative ease. This is a great way to build business agility.

REPUTATION

Uniformity can be used to protect Reputation - by limiting (unnecessary) divergences that can hamper understanding, or introduce new bugs or vulnerabilities, we can better cater to customer demand.

SUMMARY

Uniformity (like in a totalitarian regime) might also be said to frustrate free thinking, and thus impede Innovation. It helps to establish a standard, allows a business/team to flex and scale with demand, but it isn't intended to bring about radical change (change is a bad word within these regimes). With LEAN practices [1], we look to minimise (unnecessary) differences - a cause of unnecessary experts or expertise, learning, movement etc - in order to reduce waste (The Seven Wastes). Uniformity is one way to achieve this aim.

A healthy business needs a balance of uniformity (to scale) and divergence (to support change and innovation). Lean too heavily on uniformity, and you miss opportunities to innovate. Lean too heavily on divergence, and you incur sustainability impediments for your business.

FURTHER CONSIDERATIONS