Caring for software takes more knowledge than a single person can acquire.
There’s the business knowledge that makes it useful, plus the languages and runtimes and infrastructure and deployment. Then there’s security, accessibility, user experience, each interface, availability, observability, scaling, performance, data modeling, testing, networking, etc etc.
Every change to the software hits several of these areas.
It’s kinda like medicine: we collectively know more about the human body and treatments than one person could hold. When a person has more than one health problem – say, heart disease and a broken bone – they see more than one specialist. Do those doctors work together? and how?
If they form a multidisciplinary team, then each member applies their skills. The cardiologist prescribed medication and exercise. The orthopedist might recommend immobilization and surgery. Oh wait, we’d better reconcile these somehow.
In people, interventions don’t affect just one organ, just one system. Our bodies are full of interdependence.
Better than a multidisciplinary team is an interdisciplinary team. The doctors craft a care plan together. Each of them knows enough about the others’ specialty to communicate smoothly. They work together to treat the person, instead of each ailment.
Our software is full of interdependence. So the best software teams are also interdisciplinary.
Interdisciplinary teams have smooth relationships with each other. They each have increasing knowledge in some areas, and enough knowledge of everything to know when to consult each other person. They work together to fix the software, rather than each inadequacy.
Michael Feathers and Daniel Terhorst-North have compared software development to surgery. It takes a team, and it’s delicate. That’s a good description of each acute change. Overall, software development is a lot like geriatrics.
Develop a more interdisciplinary team: build familiarity with each other. Specialize, and share.