Help your Platform support the Development Habitat with CUPID
Part of a "Software Engineering Enchiridion"
(Image: My home, where habitability has been curated like a fine internal developer platform)
A platform is not a cathedral. It’s a kitchen.
Developers don’t want marble altars; they want sharp knives, clean counters, and burners that actually light. A kitchen is judged by what it makes possible, not by how pretty it looks in an empty brochure.
Carl Rogers, when creating the Person Centred approach, said "you are not the expert". You are the host. Developers bring their appetites, their mess, and their weird recipes. Your job is to make sure the tools are ready and the environment is welcoming.
Richard Gabriel called this “habitability.” Systems that feel like home. Where developers can read the code, grasp it, and bend it without breaking everything. That’s the measure of a habitat: comfortably understood, endlessly changeable.
Christopher Alexander warned us against the tyranny of the master plan. You cannot freeze the future. You can only build a place that adapts, piece by piece, to what comes next. There’s always an existing platform, there’s always a brown field. That’s why platforms thrive when amplifying small, CUPID-like properties—Composable, Unix-y, Predictable, Idiomatic, Domain-based. Easy enough to approach, easy enough to change.
But habitability is fragile. You can kill it with over-design, over-abstraction, or that hip minimalist dashboard that everyone secretly hates. Don’t compress life out of the system. Don’t make developers burn calories on stupid details. Spend your obsession on their cognitive load. Build safe, familiar abstractions.
As we've said before: Hide nothing. Simplify everything.
A habitat grows, changes, and survives the arrival of new residents—whether they’re humans or their AI agents. You’re not designing a monument. You’re tending a forest.
Aphorism
A platform is a kitchen, not a cathedral.
Rationale
Habitability fosters joy, comprehension, and adaptability. Developers stay productive when their environment feels like home. Through properties such as CUPID (Composable, Unix-like, Performant, Idiomatic and Domain Driven) you can curate a platform that supports habitability.
Some Practices
Use CUPID as target properties for your platform habitability.
Balance standardisation with autonomy.
Hide nothing; simplify everything.
Build idiomatic to the languages and ecosystem developers know.
Obsess over reducing cognitive load.
Some Pitfalls
Over-design and abstraction.
Compression that makes code unreadable.
Minimalist “design purity” that kills usability.
A Candidate Checklist
Is the platform idiomatic and familiar?
Is it easy to read and easy to change?
Does it reduce, not increase, cognitive load?
Can developers make safe, small changes?
Is custom programming minimised to the domain-specific?
Some Examples
A self-service deployment pipeline that explains itself, rather than hides behind magic YAML.
A logging framework that uses familiar idioms, rather than custom DSLs.
Guardrails that prevent disaster without boxing developers into misery.
A platform is a product that supports a habitat. It must evolve, remain habitable, and focus on making developers feel at home. Habitability means platforms feel familiar, safe, and adaptable, not sterile or over-engineered.
Focus on piecemeal change, not master plans—your job is to make developers comfortable enough to thrive.
Further Reading
Richard Gabriel, Patterns of Software
Christopher Alexander, The Oregon Experiment
Dan North, CUPID for Joyful Coding
Carl Rogers, On Becoming a Person
If you enjoyed this entry in the Software Engineering Enchiridion then you might also enjoy:
