System design is the primary constraint

You may have seen the Iron Triangle before. It's a simplified abstraction that has been used since the mid-nineteen hundreds to demonstrate the relationship between the different constraints of project management and has now made it's way pervasively into the technology arena. It attempts to demonstrate the impact on quality by the changing of scope, cost, and time. I'm going to spend the next few paragraphs explaining why I see this as a particularly ugly application that doesn't have practical place in the context of a technology team or software delivery. How we should instead think team-constrained delivery and pursue system design as the fundamental way of influencing the delivery of software.

A quick revisit of lean — a correlation with engineering quality

In Victoria, Australia, when you buy a car, you expect that vehicle to come with a roadworthy certificate which comes with certain guarantees about the fitness of the vehicle to adhere to standard road safety guidelines. You don't have to ask the question — this is a requirement by law in Victoria (and some other states) and for an extremely good reason, without this requirement peoples lives would be unnecessarily put at risk on our public roads. We also expect that a new vehicle meets all the assumptions we have of a new vehicle: that it will be able to be driven for quite a few hundred thousand kilometres, the tyres are new, the air conditioning does the cold thing, and that the radio plays more than one song. All of these expectations are covered by a mix of regulatory and consumer law, and others the competitive nature of a free market. There is a non-negotiable base-line.

First coined in the 1991 book, the Machine That Changed the World, we were introduced to the concept of lean manufacturing. The relentless pursuit of responsiveness, reduction in waste, and (most importantly) quality. Exceptional quality gives way to production lines with reduced variability. Reduced variability leads to a reduction in defects. a reduction in defects means less time and money spent on repairs and returns or double-handling. A reduction in double-handling means that lead times are significantly shortened. So, not only do customers get what they want faster they also get a higher quality product. Quality of software can actually be correlated with the pace of delivery.

Scope is the only reasonable variable in the context of a product team

Technology and software engineering is not unlike car manufacturing whereby the forfeiting of quality is paid in money, time, and lives. A baseline of quality is a prerequisite for delivering software quickly that is not a net-negative to the ongoing operation of the organisation. Appropriate testing, automation, investment in developer experience, documentation, security, compliance, data, ownership and other non-functionals that comprise maintainable delivery should fall somewhere in a category of non-negotiable.

Whether code is stored in source-control is not scope. Whether deployments are automated and infrastructure is defined in code is not scope. Whether tokens are stored securely, passwords are hashed, or code is reviewed before merge — none of that is “scope”. Scope is whether a customer can perform a function against the software and meet the needs set out by the business. How the underlying software is designed, built, and managed is up to the experienced people of the technology function.

System design is the primary constraint: a conclusion

Therefore, from the context of an organisation, adding high-performing teams in the presence of deliberate architecture and system design is how you scale (a sort of parallel to the reverse Conway manoeuvre). Work can be distributed amongst those teams using the abstractions that we know today (micro-services, micro-frontends, feature-folders, interfaces, service-oriented-architecture, modules, packages etc.). Focus on compartmentalising complexity and distributing work. The output of a team can rarely be impacted by the quality of the coffee or the number of pizzas — though that certainly doesn't hurt!