The Power of Simple Tools and Methods in Software Engineering
Key Takeaways Up Front:
- Not only complex tools and methods, but also small and simple ones can advance your work, often producing significantly better results.
- Such effective practices can be borrowed and adapted from diverse disciplines beyond software engineering, enriching your problem-solving capabilities.
- Collecting and applying these modest yet powerful tools and methods deepens your thinking, sharpens your engineering skills, and broadens your perspective as a software engineer.
In software engineering, complexity often feels inevitable. Yet, some of the most significant progress doesn’t come from heavy processes or intricate methodologies but from simple thinking tools — heuristics, principles, and checklists that not only reveal what’s hidden but also accelerate design, increase quality, and improve decision-making. These modest methods cut through complexity, helping engineers move faster and with more confidence.
I developed an interest in collecting small mathematical tools during my university years. One of my math professors often said that mathematics, among other things, is about gathering what he called “tricks.” A common example is substitution: when solving the inequality x^4 − 5*x^2 + 6 ≥ 0, the problem becomes simpler by substituting t = x*2. This transforms the original inequality into the quadratic t^2 − 5*t + 6 ≥0, which is easier to solve.
This insight led me to realize that the same idea applies broadly across my activities, including engineering, where accumulating simple but effective tools can greatly aid problem solving and design.
This article highlights only a few examples of such tools, but the full list is vast and varied, offering engineers many ways to tackle complexity effectively.
CRUD: The Fundamental Data Operation Model
CRUD—Create, Read, Update, Delete—represents the four foundational operations for managing persistent data. Originally rooted in database interactions, CRUD has become a core heuristic in software design.
- Create: Adding new data entries, e.g., inserting records in a database.
- Read: Retrieving and displaying data without modifying it.
- Update: Modifying existing data while preserving the rest.
- Delete: Removing data that is no longer needed.
Using CRUD as a checklist prompts essential questions during design: Can this data be created? Can it be read or queried? Can it be updated? Should it be deleted? Many requirement and design gaps go unnoticed until one of these basic operations is overlooked. CRUD serves as a minimal yet powerful baseline for completeness in applications working with data.
Using Karnaugh Maps in Software Engineering
Karnaugh maps (K-maps) originate from digital circuit design, where they simplify Boolean expressions and optimize hardware logic. I like to apply K-maps in requirements engineering to optimize logical requirements defining how a system reacts to digital inputs or controls digital outputs—whether real digital signals in embedded systems or GUI elements like checkboxes and toggle buttons.
Using Karnaugh maps in this way not only makes requirements easier to interpret and implement but also significantly improves testing efforts. By visually minimizing Boolean expressions, K-maps reduce the overall complexity of the logic involved, lowering development and maintenance costs and boosting system reliability. Other phases of software development, such as architecture and implementation, can equally benefit from applying this technique.
The “Why,” “What Happens Next,” and “What If Not” in Requirements Engineering
These questions provide powerful lenses into requirements elicitation and analysis:
- “Why?” distinguishes real needs from proposed solutions. For example, if I notice that there is no more space in my basement storage, before coming to the conclusion that I need bigger or alternative storage I ask: “Why is there not enough space?”. The answer is usually not that the storage is too small, but rather that I have again accumulated too many unused items. Thus, the requirement becomes to remove superfluous items. Probing with “Why?” reveals the true issues and steers design away from superficial fixes and imposed constraints.
- “What happens next?” guides us along the cause-effect axis. While “Why?” roots a requirement in its origin, the question “What happens next?” actively stimulates second- and higher-order thinking by exploring subsequent effects that ultimately lead to a well-defined and well-considered system reaction.
- “What if not?” adds a third dimension by challenging the assumption that everything follows the normal path. It reveals exception handling and fault responses that way too often go unstated. For example, in an ATM workflow, many engineers would focus on the normal scenario—entering a PIN and selecting an amount. Inverting and asking “What if not?” exposes the missing cases: what if the PIN entry does not succeed? This leads to retry policies, requirements on user feedback etc. These deviations are as much part of system behavior as the intended flow.
The Rule of Three: Knowing When to Rethink
I use a heuristic for which I borrowed the name and call it the “Rule of Three” until I come up with a better one. It suggests that when something happens or is encountered for the third time, it deserves to be treated differently. The threshold of three can be adjusted if needed, of course.
For instance, writing atomic requirements is usually a desirable practice. Yet, if three or more similar requirements start to repeat with only minor variations, it signals the need for a better representation—perhaps merging them into a table instead of several atomic items.
The two main values of the “Rule of Three” heuristic are that:
- It supports decision-making by setting a clear threshold for change.
- It challenges and improves established solutions in pursuit of better outcomes.
HAZOP: A Guideline-Based Analysis Method
In this article, I focus on HAZOP guidewords only, rather than the full methodology. These guidewords serve as mental prompts that stimulate imaginative thinking about what issues can arise within a system or its elements.
Common HAZOP guidewords include:
No (Not, None), More (More of, Higher), Less (Less of, Lower), As well as, Part of, Reverse (of intent), Other than, Early, Late, Before, After, Extra, Wrong, None, No information, Wrong information, Clarity, Training, Abnormal conditions, Maintenance, Safety.
Examples of how to use the guidewords:
- No: Total absence or negation of intended action or condition.
Failure example: No flow in pipeline when flow is required. - More: Quantity or intensity greater than normal or expected.
Failure example: Higher pressure in a vessel than designed. - Less: Quantity or intensity less than normal or expected.
Failure example: Lower temperature than needed for a reaction.
By systematically applying these guidewords to each part of a system, the HAZOP method encourages comprehensive exploration of deviations, helping teams uncover risks and operational problems they might otherwise overlook.
The Beauty of Modest Methods
The common thread in all these techniques is their modesty combined with depth. They require minimal process overhead yet significantly improve clarity and completeness by encouraging cognitive discipline.
The more such tools you collect in your toolbox, the better, as each has value in particular situations—helping you avoid the “man with a hammer” cognitive bias and seeing each problem as a “nail”.
