Software Engineering as a Habitat
Viewing Software Engineering through the lenses of People, Experiences, Platforms and Habitat
“we don’t just build systems, we inhabit them… make them somewhere everyone enjoys, even loves, living.”
In the past I’ve struggled to explain the need to invest in software architecture, development and engineering platforms and tools, even broad approaches such as observability, data mesh, and chaos engineering. When viewed through a focussed lens of the product’s end user experience alone, these ideas always felt secondary, nice to have, peripheral… de-prioritisable.
Until I realised that our systems are not just products. They’re not just for the end users. They are for a much more diverse, and important, population. A population that doesn’t just use the system — a population that inhabits it.
Habitat and Inhabitants; Helpful Metaphors
Software engineers, product managers, quality assurance engineers, devops automation engineers, business operations. These people don’t just build and run systems, they experience them. They inhabit them.
I’ve found that realising the socio-technical system of software solution engineering is a habitat has been helpful to explain and reconfigure the balance of investment that we make to establish and improve the different experiences of the people that live and work in that habitat. We inhabit the systems we build and so we experience different facets, frustrations and joys as we go about our valuable work.
Architecture that Considers Different Inhabitants, Different Experiences, Different Platforms
Each different person, each different experience is valuable to the people that inhabit the system. It then follows that those experiences are just as valuable to the organisation that the system also serves.
A good example of the power of viewing software engineering as a habitat is some recent work I’ve been doing to shape the strategy in a financial services company. It’s easy and natural for the decision-makers in the company to view the system solely on the merits of the experience it delivers to its users — they are the customers, they pay their bills, they are the revenue and the profits, so of course their experience is a priority.
But the user is just one, albeit extremely important, inhabitant of the system. Software engineers are responsible for building, evolving and, increasingly, running the technical services that form the value chains of the system. Their experience counts.
Product Managers care for and are measured against how the product evolves to meet current and future user demands. Their experience in the habitat also counts.
Viewing the system as a habitat has helped me and my colleagues to understand the multiplicity of people and experiences that are valuable to the system’s function. And this matters most when you start to define, strategically, the architectural direction of the system.
Recognising this panoply of different people and experiences necessary and important to the success of a system you can establish an architecture, a structure, that can support their needs. You can explore the optimal structure to support the needs of the users, and the engineers, and the product experts, and the data analytics and science people. You can architect resilient systems that can support the stresses that each of the different experiences will come under as they evolve and adapt.
Each experience can be considered, invested in and prioritised in accordance with the return on investment and important properties you seek from your system. An experience gets its own roadmap, tools, practices, even platforms. By using the contextual metaphor of a habitat, and a complicated or complex one at that, you can explore, probe, sense and respond as you establish the best platforms for each of the experiences that the system’s architecture looks to support. New people and experiences can be discovered and added to the catalog, ready to have their own needs met with a new set of tools; a new platform.
Habitats over Just Products
People do their best, most creative work when they feel safe, respected, engaged and unencumbered in their workflow. Viewing your systems as habitats, not just merely as products, opens you up to the possibility to invest concretely in the experiences that drive those generative conditions.
Want to improve the experience of how system’s are debugged in production? Look to observability. It’s important to improve the experience of how we adapt the product roadmap? Look to improving the way we manage work through the system. Want to explore how everyone and everything will respond to a surprise? Chaos engineering will help better that experience too.
Working in software engineering, we live so much of our lives inhabiting the systems we create. By reminding ourselves of the diversity of this habitat we can respect and invest in the diverse experiences that are crucial to helping people perform at their best. We get to construct places where we can all do our best work.
For me it all started with understanding that we don’t just build systems, we inhabit them. I realised that, as an Engineering Manager, it was my job to engineer the habitat itself. To engineer a place where everyone enjoys, even loves, working and living.
