Over the past few years, I've been on an exploration of how software, and the process of creating & maintaining it, has become so complicated, difficult, and expensive. One theme I'm continually led back to is the concept of boundaries.
The whole monolith vs. microservice thing is just a red herring for the fact that we suck at managing boundaries in any formal/explicit way.— Nate Abele (@nateabele) June 10, 2015
Boundaries are omnipresent in all aspects of the software industry, yet rarely acknowledged or thought about as a first-class concept.
Whether abstract or concrete, having a unified mental model for reasoning about boundaries should yield some interesting insights. Here are a few examples from across the spectrum:
- Queries & cursors are boundaries between databases and applications
- HTTP messages are boundaries between apps and browsers, or apps and other apps
- Queues are boundaries between apps and expensive jobs
- Time is a boundary between different states in an execution context, (object-oriented) application, a database, a filesystem, the universe, etc.
- Apps are boundaries between me and data or functionality that I care about
- Installation is a boundary between me and an app
- Programming languages that I don't know (or that haven't been invented yet) are the boundaries between me and the ideal expression of some problem domain that I face
- Wireframes are boundaries for communicating about user interfaces between designers, project stakeholders, and developers
- HTML & CSS are boundaries between wireframes and real user interfaces
- Code is a boundary between ideas and computers
As the tech community, these are a few of the boundaries that we face today. Some of them are useful. For the ones that aren't, our future is on the other side of them.
The next wave of innovation in software development is going to come about by treating time and boundaries as first-class things.— Nate Abele (@nateabele) April 22, 2015