Designing Homesteads Instead of Mansions
We usually lean toward terms and methods from other engineering disciplines in software development. In some ways, this is good, and in others, it isn't. All engineering disciplines have a strong history of learning from the past and improving on what was done before. However, there is one aspect where I do not think software development should follow others, and I'm sure many know it well, the construction analogy.
The Construction Analogy
"We've got to start with a solid foundation and work from there."
Software development strategy is very frequently related to buildings and construction. We tend to describe software as a single building with many rooms and interconnected hallways. When using this analogy, of course, you need a strong foundation. More importantly, you need a clearly defined plan for everything about the building before you start. It isn't possible to build the proper foundation without knowing everything about how the building will be used. In construction, these are engineering drawings, blueprints, or plans. Something that outlines the exact dimensions and locations of everything. Software teams call these design documents. Something that must be defined before we start and shouldn't change once we begin.
Many have heard something like:
"Well, they changed the requirements!"
Is There a Better Analogy?
Whenever I think about this topic, this comic pops into my head.
The underlying tone of this comic is that the result is incorrect or a lousy architecture.
I look at it differently, though. The result represents a robust software architecture. Each building can be considered a stand-alone unit: "Encapsulation" and "Abstraction." They all have clearly defined inputs and outputs, "Interfaces." There is even a hint of "Polymorphism" in that image.
This is still a construction analogy! It is, but in a different sense than most consider.
The Homestead Analogy
I like to think of it as someone trying to start a homestead on an empty land. The first thing to build isn't a multi-story mansion or its foundation. It will be a single room with four walls, a roof, a bed, and a cooking place. Our friends who practice lean/agile development would call this the minimum viable product (MVP). The goal is to get here as fast as possible because it is life or death for a homesteader.
Once the basic needs are satisfied, it's time to expand. Maybe it's time to add a barn, shed, bedroom, or bathroom. These are features that add utility and value to the house. When expanding, the features may be additions to the original building, rooms, or separate structures. The key here is that, while they may have been part of the long-term plan, these improvements aren't designed and locked in from day one. Additionally, all these improvements can be considered standalone with their foundations, walls, doors, and possibly windows.
Don't Design a Mansion
The problem with using traditional construction and engineering analogies for software development is that software isn't physical. Software will always be different because it lives in the digital world. The rate of technological advancement and improvement will keep best practices constantly changing. However, we will always need more adaptable and evolving software.
Plan to make a great destination resort when building the next great thing, but wait to lock yourself into the final design. Start by creating a structurally sound shack and adding to it as your plan evolves. Ultimately, you may end up with the craziest tree house ever imagined, but it will be rooted in sound design and adaptable architecture.
Comments
Post a Comment