Continuous Design (Model-Minded Development)
I’ve become quite interested in how teams of developers collaborate to build software.
One thing I’ve noticed is that senior software developers can walk up to a whiteboard and give an impromptu talk on how their software works, explaining both the details and the broad strokes. Most importantly, they connect the specifics of this system to general architecture patterns, domain models, design patterns, development patterns, or programming styles.
If you’re a developer, you want to be that chalk-talk ready person. If you’re a team lead, you want a whole team of them. And if you’re a manager, you want to grow them as quickly as possible.
It’s surprising that modern software development processes do not focus on this aspect, instead focusing on delivering business value in the short term (weeks or months). Maybe that short-term focus on delivery is the best path to grow such developers over the long term, but I’m skeptical. I think it’s more likely that we must balance short-term and long-term objectives, and if we relentlessly focus on delivery then we get fewer chalk-talk developers.
I’ve been working on answering questions like these:
- How do chalk-talk developers think about a system?
- How do we get more of them, more quickly?
- How do developers reason through a problem and write code for it?
- How does a team of developers collaborate to solve one problem?
- How do our processes help or hurt?
- What happens when team members change?
- What does it mean to write good code?
- Is the important stuff in the developers’ heads or the code?
My belief is that the use of models is central to answering the questions. We use models to amplify our own cognitive abilities and to coordinate our actions with others.
Models do not always get the attention they deserve for a few reasons:
- We underestimate the individual cognitive task of programming.
- We underestimate the group coordination task of programming.
When I see chalk-talk developers explain how they solved a problem, I see them explaining how they wove together models of the problem domain and of the solution, reusing existing ones and innovating when necessary. The arguments they make have the form “you can see this solves the problem because …” and rely on elements in the models, not line 463 of a particular file of source code.
In many ways my ideas and beliefs here are nothing new – we’ve been talking about using models in software development as long as we’ve been coding, but attention to the topic waxes and wanes. Good modeling ideas are often discarded when the technology that carried them becomes unpopular.
In an effort to separate the durable good ideas about modeling from the transient carriers of them, I’ve coined the term Model-Minded Development and have re-used the term Continuous Design.
Model Minded Development generalizes across DDD, Design Patterns, architecture, TDD, and coding styles. The defining characteristic of senior software developers is their facility with Model Minded Development as it enables them to operate at an advanced level.
Essays
My essays in IEEE Software have been on the topic of Continuous Design. I suggest you look at this short summary, which explains the big picture and how the essays relate.
Talks
I’ve given a few talks on this topic and for now they are the best expression of the ideas. Start with these:
- Model-Minded Development, Part 1
- Model-Minded Development, Part 2
- Continuous Design of IT Systems
- Code is King; Let’s Think in Code
If you are still interested, this older talk pulls in more angles from psychology to motivate why models are helpful.
Related blog posts and pages
These are generated based on tags in the postings.
- Continuous Design (Model-Minded Development)
- IEEE Software Essays on Continuous Design
- SATURN 2019: Continuous Design of IT Systems
- We Are Developers 2017: Model-Minded Development (part 2)
- GOTO Berlin 2016: Model-Minded Development
- GOTO London 2016: Model-Minded Development
- SATURN 2016: Model-Minded Development
- WICSA 2016: Building Theories is Building Value
- Conceptual Models of Software Architecture
