Image courtesy of https://www.vectorstock.com/
This article seeks to establish the concept of Constraint-based Design (CBD), especially as it pertains to code design, system architecture, and the Software Development Lifecycle (SDLC). There are similar articles and scholarship on this eponymous term, however, I am to establish CBD as critical to all participants of software projects.
Constraint-based Design is the idea that the capabilities of a system or solution are best understood not only by its features and capacities, but also, if not more so, by its limitations and constraints. CBD is a very effective paradigm to adopt during the design and architecture phases of SDLC. It, paradoxically, makes for simpler and easier designs and problem-solving sessions by limiting the decision points and options to well-understood and predictable patterns. It also makes for better developer experience as engineers come to rely on, familiarize, and continually enhance known patterns and solutions. Stakeholders, Project Managers, and Product Owners are also able to make much more informed decisions when considering customized solutions for specific problems solved by CBD systems. Lastly, project costs are ultimately reduced as CBD forces implementations into highly reusable components that are very well understood and robust.
A real world example
If you needed to fly somewhere. You would task engineers to build a plane. A plane is very good at flying; that is its singular purpose and responsibility. In some circumstances however, it turns out that it may be useful to have a vehicle that can both fly and float. Thus, the plane is redesigned for seaworthiness and liquid propellers. This is where care needs to be taken. This is not a case against amphibious planes, that seems cool and situationally useful, but it illustrates the problem when there is a lack of CBD. What if this vehicle needs a torpedo bay ? How would a torpedo bay effect its flying ability? Would adding a bomb door cause the vehicle to sink? The analogy tells us that adding features, even a singular feature, can complicate or adversely impact the other features offered by a solution. The analogy is also that of the need to beg an important question, does this vehicle even need to be amphibious? CBD is essential in driving better design conversations. Perhaps some situations merit the amphibious vehicle, but a team that embraces CBD must first ask themselves, are there alternatives that satisfactorily solve the need at hand? With the constraint in place that the solution must be an airborne vehicle, then the design team is forced to consider more practical solutions to whatever the need is, and also consider the cost and benefit of any such design. The truth is that every system has constraints and limitations. Building systems without adopting CBD doesn't result in boundless, omnipotent solutions, only solutions where its shortcomings are poorly understood.
CBD is a mindset
CBD is ultimately a mindset; a paradigm we should all advocate and adopt. With it, stakeholders better understand the limitations and capacities and strengths of their solution. Product Owners should realize better returns on resource investment by solving variations on recurring problems by acknowledging the constraints of a system and leveraging the existing features and capacities. Architects will build frameworks designed to solve anticipated problems; these frameworks are the primary source of constraints, and by creating such constraints, they can also make empowering assumptions about the system and system state which can be exploited to provide predictable, regular, and well understood solutions to known typical problems. Solution designers use existing patterns precedent to compose solutions to new problems. Engineers work within the confines of tools and states where certain assumptions can be guaranteed and exploited.
Conclusion
It is usually more beneficial, and informative, to view systems and their constraints, rather than their features. Understanding and embracing system constraints protects stakeholders from mal-investments in dysfunctional and confusing solutions, leads to better and simpler designs and yields higher quality and more robust implementations.
Top comments (0)