Constraints are equally frustrating and challenging. And by challenging, we mean the force that compels us to find ways to break the barrier and forge a more reasonable, more convenient path. Such are constraints. In software development, this is likely to occur in software architecture, where overly-tight architecture becomes a problem come the time it is necessary to upgrade or re-implement the system.
In The Theory of Constraints (TOC), according to Goldratt, a constraint can be found anywhere in an organisation, including technical constraints in software development like environment creation, code deployment, test setup and run, and architecture. The factors that create any of these constraints can be internal or external, and can affect the system, and the business that uses it, when it becomes necessary to decouple, upgrade, or re-implement the system. So what if the TOC does is it aims to eliminate factors that cause these constraints through a series of steps and then evaluate the effectiveness of the solution by using a certain set of measures as indicators. The process of removing these constraints is done by using the 5 Focusing Steps by Goldratt. And the effectiveness of these steps are measured by the 3 Essential Measurements.
The 5 Focusing Steps
Below are the 5 Focusing Steps in relation to the constraints in software development
1 – Identify the constraint
In software development, the constraint can either be technical or business. And in dealing with these limiting factors, it is important to properly differentiate a constraint from attributes or requirements, else, the wrong problem is targeted and no amount of work can turn that around.
In the case of a technical constraint, it’s almost always is the code. The language that is used to create the code cannot be changed midway or at any part of the project. Overly tight architecture is another constraint, where it may reduce the flexibility of a software as it piles up on new features.
2 – Decide how to exploit the constraint
Using the same example given above, one of the bigger constraints aside from the code used in building the program is the architecture of the software. At this point, the dev team needs to make a decision whether they are to build up on the existing architecture, despite the certainty of the program becoming unyielding to further changes in the future, or follow a different approach that allows interdependent features that comprise the software to present itself as a whole, without losing its ability to work compatibly with newly added features and various source codes, as well as the capacity for re-deployment.
Once the constraint has been identified and established, the next step is to find a way to alleviate it, either by improving it or by eliminating it.
3 – Subordinate everything else
Full consideration is given to the constraint while the solution is being implemented. The consideration for the non-constrained areas are adjusted to a degree that allows the constraint to operate at optimum level. If the requirements demand that a program is built a certain way using a preferred coding language, then this restraint is a non-negotiable. This has to be fulfilled, no matter what, and as such, all other factors are subordinated to ensure that everything is done around the non-negotiable constraint.
Another constraint could be using open source code. It’s possible that a stakeholder requires the use of open source code, while another one may have a “shopping list” with which the devs must adhere to, and use only code that is indicated on said list. In this case, fulfil the requirement and set aside any preference despite having the knowledge and understanding that these other alternatives work, and may actually even work better. When this constraint is overcome and the project becomes successful, skip to the last of the 5 steps, and develop ways to standardise and improve the finished product even more.