ROBUSTNESS OF SOFTWARE ENGINEERING
THROUGH HYPER-AUTOMATION
HIGH-LEVEL AUTOMATION: HYPER-AUTOMATION
HIGHLIGHTS
- “Robust engineering” aims to create products that are of high quality, reliable, and cost-effective.
- The speed of software development needs to increase.
- The need for Software engineers is growing 5–10 times faster than the world’s population.
- Growth by hiring more engineers is an anti-pattern for Robustness and Software Quality.
- I see Hyper-automation as the key differentiator in the software engineering process and believe that robustness cannot be achieved without Hyper-automation.
“Robust engineering aims to create products that can withstand variations in their environment and use and are high quality, durable, reliable, and cost-effective.”
ROBUSTNESS
The Taguchi method is a popular approach to robust engineering. The method was developed by Dr. Genichi Taguchi after World War II and is used by many companies around the world to reduce product costs, improve quality, and reduce development time.
The speed of software development has become one of the survival factors of companies to differentiate themselves from the competition. Growing software stacks, faster product deliveries, growing need for features, and faster employee turnover of engineers, place ever-increasing demands on the software development process.
I see hyper-automation as the key differentiator in the software engineering process. It enables a strategy to avoid errors as early as possible in the development process, through the use of formal modeling languages & GenAI, code generation, and automated verification and validation. I believe that with hyper-automation, our customers can significantly improve the robustness of the software systems they develop.
AUTOMATION
In general, we try to speed up a process and increase value with automation. It allows for shorter feedback loops and fewer human errors in work with repetitive steps, resulting in higher quality and robustness.
We can apply automation both in the primary value stream (building the product) and in the secondary value stream (building the development environment).
There are two commonly used strategies to increase value:
- Increase the number of engineers who create value. I do not recommend this strategy because it is at most a short-term solution. It is also a very expensive solution because costs have to be incurred for each engineer for recruiting and streamlining processes, and there are permanent costs to be incurred for education, licensing, tooling, etc.
- Increase the amount of value creation per engineer. This is the preference, where we see that especially in the secondary value flow, extra value can be added by employing automation.
With traditional R&D investments, the goal is to get back Y Euro in value every year with an annual investment of X Euros, but this is usually not realized. The ROI on an R&D investment usually decreases, over time, with the same annual investment.
We can break this pattern with the help of Hyper-automation.
WHY AUTOMATION ALONE ISN’T ENOUGH
There are several key global trends that are driving us to do ‘more’:
- Time-to-Market
Entering the market too late will result in a loss of market position. - Increasing enforcement of regulations
Requires that the quality, durability and robustness of our products must be improved. Yesterday’s acceptable quality is no longer acceptable today. - The Software Explosion
The software in products is becoming more and more important and extensive. Adobe Photoshop, for example, consisted of 10 thousand lines of code in 1990 and a whopping 4.5 million lines in 2020. - Increasing domain complexity
E.g., the field of particle physics requires increasingly complex systems, such as CERN. - Increase in historical complexity
E.g., For a system such as a server rack, more and more is added over the years, which threatens to make it confusing. - The world doesn’t offer enough talent to meet the demand for Software engineers The need for Software engineers is growing 5–10x faster than the world’s population. This means that we can’t keep scaling with the number of software engineers.
In addition, growth in the number of software engineers comes at the expense of robustness:
- People make mistakes, so doubling the number of people also doubles the number of mistakes (think of the term ‘Monday morning car).
- We know that, on average, X number of errors are made per thousand lines of code. Doubling the code therefore also means an average doubling of the number of errors.
- Growth of an organization causes growing pains in the field of management and integrating/training the new engineers in the company culture and way of working, resulting in a measurable reduction in speed and quality.
We can conclude from this that the mere increase in the number of software engineers is an anti-pattern for robustness and software quality.
If we look at the V model, we see that automation is currently mainly on the right-hand side.
Think of static code checks, tests, and construction activities that are automated, for which Quality gates are set up.
However, this ignores all other aspects such as the aforementioned trends and the growth in knowledge and the organization that engineers have to deal with.
A company must continue to focus on its core activities and preferably (hyper-)automates all context activities so that its own engineers do not have to worry about mastering new tools, techniques, and standards and can concentrate on building the product.
HYPER-AUTOMATION
By shifting (part of) the R&D budget to hyper-automation, we can turn this trend around into an increase in ROI.
With hyper-automation of tools and resources for the primary value stream, hyper-automation allows engineers to focus on their core business and deliver value faster.
To explain the difference between automation and hyper-automation, let’s take the example of an airport shuttle bus that takes passengers to and from their planes.
One of the core tasks of an airport is to take passengers to and from the aircraft. This is a dynamic process because it is only at the last moment it is clear on which runway the aircraft will land. The airport must constantly communicate the updated timetable to the bus and the bus driver must comply with legislation, such as owning a bus driver’s license and having domain knowledge of the airport (where to drive, at what times, the local rules, etc.).
By automating this process, it can be made more efficient and give passengers a better and safer experience. The timetable can be constantly updated on the driver’s screen and traction control and braking can be (partially) automated. However, the passenger experience will still vary from bus trip to bus due to the difference in driver and driving style and the airport needs to invest heavily in continuous driver training and recertification.
Through hyper-automation, we hide all contextual domain knowledge (driving skills, legislation, etc.) and we get an autonomously driving shuttle bus. The experience for the passengers is now the same for every trip and all the domain knowledge of ‘driving a bus’ now lies with the organization that builds the autonomous shuttle bus, and no longer with the airport.
This is similar to the shift in other industries, such as car manufacturers, for example. They no longer hire welders, but they are hired by the welding robot manufacturer. The car manufacturers buy the welding robots.
Increase in value through hyper-automation
By hyper-automating, engineers have more ‘time’ to work on core activities and thus add value. Human error is reduced, which improves quality, robustness, and time-to-market.
The traditional approach to increase the value per engineer is to add more and more standards and generic/COTS tools into the software development process, which software engineers need to master. This requires more knowledge and training for each engineer. Not every engineer will master this easily and quickly, which can often be recognized by the fact that within the organization the focus is on ‘senior’ engineers who are needed in the team to become successful.
With hyper-automation, we see a different approach: that of a tailor-made environment with hyper-scaled automation with a focus on added value. The knowledge and skills that the engineers should gain for this new tooling is now hidden in the automated part, which also makes us less dependent on senior-level engineers.
We apply hyper-automation together with the system thinking method. We do not only apply it to the right side of the V-Model but also during the entire engineering process, where there is still a lot to be gained, especially on the left side of the V-Model.
Hyper-automation includes the following measures:
- Model-Driven (Software) Engineering supported by automated tools.
- Interface modeling and generation of interface codes, e.g. with COTS tools such as ASD, Dezyne, CocoTech, etc.
- Generic modeling and code generation such as U/Sys-ML, State Machine modeling, etc.
- Automating all repetitive tasks to remove human error and increase speed.
- Domain-specific modeling and code generation: Hyper-automation to ‘hide’ domain-specific knowledge and skills. (Gen)AI is a technology that is very useful here.
All these measures affect quality and an organization mustn’t fall for the myth that there is a trade-off between speed and quality. Empirical evidence shows that we need high-quality code to move quickly.
SUMMARY
- Hyper-automation
Automate all repetitive tasks (with the help of experts/partners) and do this across the entire engineering process. - Get rid of bugs
It is more cost-effective to prevent bugs than to detect and fix them during testing by using, for example, coding guidelines, interface modeling, and MD(S)E initiatives. - Shift Left & Testing
It is important to not only implement a good agile test pyramid strategy, but to implement a ‘Shift Left’ to the left side of the V-Model. - Fail Fast / Early Feedback
Short feedback cycles are known to improve the quality of. Higher quality means that we can accelerate. - Enforcement
Rules don’t work if they’re not enforced. Define and measure KPIs for use in quality gates, anywhere in the V-Model.
About the author
Chief Solution Architect @ Capgemini Engineering
Leads the Center of Excellence “Quality Assurance” that focuses on Software Quality Engineering and Testing. To accelerate and reduce cost while creating higher quality software by automating software engineering and testing processes.
https://www.linkedin.com/in/richardvandelaarschot/
richard.vandelaarschot@capgemini.com
