Moving from Building Software to Engineering Software
By Alex Martins, Advisor — Continuous Quality, CA Technologies
Let’s face it: the way we build software looks downright old-fashioned compared to the way other modern goods are manufactured. It’s time for us to steal lessons from other engineering disciplines so we can finally bring software engineering to the level businesses really need.
Unless we go from building software to engineering software, we’ll never get there. There, I said it!
Think about an automobile assembly plant: it essentially assembles parts manufactured by hundreds or thousands of suppliers. Parts such as bumpers, brake pads, windshields, tires, rims, exhaust pipes, screws, nuts, bolts, washers, shocks, springs, etc. — are commonly manufactured by third party suppliers and later assembled into the complete vehicles we use for daily transportation.
Take a braking pad for example. As the pad is manufactured, a sonic vibration measurement probe is assessing the quality of each pad as it is being manufactured to ensure it conforms to the specifications. If the pad doesn’t meet the specifications, the anomaly is detected in real-time, as the pad is manufactured. An alert is triggered, and corrections or adjustments are made immediately so that the brake pad manufacturing process can continue for the next pads. That prevents hundreds or thousands of brake pads from being manufactured and potentially shipped with defects to the automobile assembly plants.
There is a very similar process for real-time detection of anomalies in the windshield adhesive bead application process. It is very costly to detect the adhesive was not properly applied to the windshield by the time it is installed on the vehicle. Modern assembly plants prevent this increase in manufacturing costs and waste by using 3-D laser displacement sensors mounted on the robot applying the adhesive to the windshield. As the adhesive is applied, if there are any anomalies detected, an alert is triggered and the application process stops for all windshields in the line. This is the modern-day, automated version of the “Andon cord.”
By continuously measuring for quality in the manufacturing process, it’s guaranteed that the brake pad, windshields (and other parts) can be immediately attached to the rest of the vehicle. Because all parts are known to have been manufactured with this same high standard of quality, at the end of the assembly, a technician can simply turn the car on and drive it to the parking lot. That last act serves as an integrated test with the final assembly of all parts.
Can you imagine if the automobile factory was responsible for individually testing the thousands of parts that make up a car? It’s not scalable, it’s not economically feasible. And yet, that’s how we’re “manufacturing” software today. It is no surprise that the total spend on software R&D is growing at over 50% annually, while R&D for traditional products is decreasing by a similar amount.
A new approach is needed. That’s what the Modern Software Factory is all about. It’s about applying engineering and manufacturing lessons from other industries to software. With a modern software factory, quality is engineered in throughout the “manufacturing” process, as opposed to testing after software is built.
We Can Do Better
With technology advancements in the past 10 years, companies have been able to include automation in most processes across the software development lifecycle. From code development, to build creation, deployment, environment provisioning, virtualization, test automation, code release, etc. — many of these tasks have been automated.
However, that only solves one part of the problem, which is moving the application to the hands of the users faster. We still can’t tell for sure if what the users are getting is actually what was intended, or in other words, if the application had the expected quality, as I’ve previously written.
Picture this: a major automobile factory receives a shipment of thousands of brake pads, but the pads don’t fit the wheels they were built for. Progress stops until the next good shipment is received. That doesn’t usually happen because in the manufacturing world, they’ve figured it out. We can too.
Most mature companies that have been able to accelerate the software lifecycle through Continuous Delivery and/or DevOps only realize after the fact when software misses the mark. That is, users didn’t perceive the value of the intended update or new application. (Or, in the example, the brake pad sent to the assembly plant is too big). Then they have to go back to the drawing board and try again. The benefits of this automated way of developing and releasing software is that it enables teams to fail fast and learn fast, which in and of itself, is a huge benefit from traditional software development approaches.
Still, we can do better. Can you imagine if you bought a car at a dealership and, when you turn it on in the dealer’s parking lot, the car doesn’t move because there’s a problem with a component inside the transmission? The car would have to be decommissioned and taken apart to remove the transmission from the car, which would have to be opened, troubleshooted, and fixed. That just can’t — and doesn’t — happen in a massive and modern manufacturing environment.
But it does happen in the software development environment. Software is still being built almost artistically. Which may be acceptable if you want to build it once and let it run for eternity. However, we all know that in today’s business environment, software will be required to change constantly.
We need to transition our development approach from hand-crafting software to engineering and manufacturing software, using lessons from other industries to achieve repeatability and scalability. Luckily, we can apply many concepts from to modernize our software factory.
In my next blog, I will explain how we can get started on this journey to a modern software factory — and how continuous testing is the key to the move from building software to engineering software. In the meantime, I encourage you to read more about Continuous Testing at: www.ca.com/continuous-testing
