An oxymoron is a figure of speech that pairs two opposing words. There is one I include in my software-engineering repertoire: enabling constraint. We can enable one activity by constraining another. Let’s explore how this paradoxical effect can be applied to software engineering.

Examples

Enabling constraints are pretty generic. Here are two examples of how they were applied in other domains:

Steve Jobs

I think Steve Jobs’ strategy when he returned to Apple in 1997 (to save them) is an example of enabling-constraint thinking.

His strategy was to produce only four products. A desktop and a portable device, both with consumer and professional models. He got rid of the plethora of other Apple products.

He constrained what Apple worked on to enable them, with focus and simplicity, to develop those four products to perfection. Genius!

Sport

Sport is a composition of freedom and enabling constraints. Let's consider rugby union.

World Rugby says the following about the Laws of rugby:

The Laws of rugby are developed with two central principles in mind: firstly, to allow players to play within the spirit of the game, and secondly, to protect the welfare of all players.

The laws enable the players by constraining what they can do. They also enable interest in the sport. Who wants to play or watch a game without rules?

Agile

Here's an enabling-constraint perspective on Agile.

Iterations

Working in iterations constrains us from planning, analysing, and designing (in detail) too far ahead. But enables us to validate our assumptions (about the project) with the feedback from completed iterations.

Constraining initial-plan desires

Agile says responding to change is more valuable than following a plan. If the feedback (data) produced by completed iterations signals we won't be able to meet all the requirements in time, it means our initial plan will likely fail.

If we constrain the desire we have to forge ahead with our initial plan, it enables project managers to respond to iteration feedback early enough. They'll then have enough time to 'turn the knobs' of the iron triangle (tweak the plan) to drive the project to the best possible outcome.

Daily standup

The daily standup enables a team to quickly assess their progress and give feedback to those in attendance. Constraining it to 15 minutes max enables dynamic and productive feedback. It’s a standup, not a sit-down, after all.

Kanban boards

Kanban boards can help us visualise and optimise our workflow. The WIP limits on columns constrain the number of stories done in each. But it enables us to focus and identify bottlenecks quickly. As a result, we'll be able to complete more stories. It’s better to complete 80% of the stories in an iteration than 80% of each.

Extreme Programming (XP)

I love XP! It's my favourite Agile process. As a tech lead, I've relied on its practices to make our engineering productive.

XP's Circle of Life depicts these practices in a memorable way:

Pair Programming

Pair Programming constrains us from always coding alone. But it enables our developers to have context of each other's work, promotes collaboration, and bakes peer-reviewing into the coding process.

Test-Driven Development (TDD)

TDD constrain us such that unit tests must be written before the functionality. But it enables us to know if our code still works right after we've changed it. And to write more decoupled code. Because we have to decouple the code to make it easy to test.

Refactoring

Refactoring (a là the Campground rule) constrains us from just writing new code by requiring us to continuously make existing code (even if our peers wrote it) a little better. This enables our codebase to stay clean.

Simple Design

Most developers seem inclined to over-engineer solutions just 'in case' unnecessary parts are needed in the future. Simple Design constrains this inclination to enable sophisticated solutions and waste reduction. YAGNI!

Coding Standard

A coding standard constrains us from coding however we want but enables developers to understand each others' code quickly.

Sustainable Pace

A software project is a marathon, not a sprint. Sustainable Pace constrains how often we work overtime to prevent us from burning out. This enables us to stay productive in the long run.

Continuous Integration (CI)

CI became so popular that it’s now part of DevOps’ DNA. CI pipelines with quality gates constrain us from merging broken or not-up-to-standard code into the main branch. But it enables us to automate the enforcement of standards and have a trunk always ready to ship.

Small Releases

Small Releases is about releasing small batches of features to the customer early and continuously. It's the opposite of Waterfall's Big Bang approach, where all the features are released towards the end of the project. To enable this requires constraining large-release desires within the team.

Customer Tests

They are also known as Acceptance Tests. It's a practice where tests are included in the specifications of stories. It constrains developers from declaring a story as developed until all its acceptance tests have passed. But it enables more quality.

Whole Team

The practice where those working on a project co-locate (sit together). It constrains individual members from sitting wherever they like. But it enables serendipitous and nonverbal communication.

Social Thought

Who should choose enabling constraints? Tradition suggests the answer lies in a balance of subsidiarity and solidarity.

Subsidiarity is a principle that says regulation should happen on the local level. By this principle, the local leaders of a team, such as team leaders and tech leads, have the authority to choose their enabling constraints.

Solidarity is about the unity, alignment, and good of the whole. It motivates a central authority (such as the federal government in the USA) to regulate the entire organisation. A company's high-ups choose the enabling constraints in this view.

Because a central authority isn't in the trenches, they may not know what the best solutions for local issues are. A balance of subsidiarity and solidarity is therefore needed.

Conclusion

We enable ourselves with constraints. How ironic! Sport. Agile. Kanban. DevOps. We observe it all around us. It takes discipline to play along, though, to agree to be constrained. Conscientiousness, the personality trait, is required for that. We should, therefore, strive to have proper enabling constraints and conscientious members if we want to be a high-performance team.

P.S.

This article is an extension, with several changes, of the original Enabling Constraint article I published on Apr 24, 2023.