Meet Mooly Beeri

Mooly Beeri has spent almost 30 years working in software, from startups to companies including Microsoft and Philips. His work has included large-scale software transformations in industries such as automotive and healthcare.

“I had luck and I was fortunate to build the first software center of excellence for Philips. And then I enjoyed the space of software excellence.” – Muli Berry

The Automotive Sector: A Datacenter on Wheels

Modern cars are increasingly software-defined systems, with different suppliers responsible for components such as braking systems, infotainment, and autonomous driving functions.

As Mooly explains, the challenge isn’t just developing those individual components. They all eventually have to work together as one system.

That makes integration a major part of automotive software development. A component can work perfectly well on its own and still cause problems when combined with everything around it. With multiple suppliers and development teams involved, finding and fixing those problems can result in long development cycles and a considerable number of bugs.

Dealing with Bugs at Scale

Managing software at this scale can mean dealing with thousands of defects every month. Mooly describes how Original Equipment Manufacturers (OEMs) may spend years stabilising software before a release, a very different world from the rapid update cycles common elsewhere in the software industry.

At that scale, fixing individual bugs isn’t enough. Teams need processes that help them understand where defects are coming from, how to deal with them, and how to prevent the same problems from returning.

Fix the Process, Not Just the Bug

Mooly emphasizes the importance of looking beyond individual bugs and understanding their root causes. If the same kinds of defects keep appearing, the development process itself may need attention.

Once a recurring failure is understood, teams can create specific tests for it and add them to automated test suites within a Continuous Integration/Continuous Deployment (CI/CD) environment. Faulty code can then be caught before it moves further through the development process.

Communication Matters Too

Testing isn’t only about tools and automation. Communication between development teams and other stakeholders matters as well.

Mooly points out that bringing different disciplines together and encouraging openness between teams can help reduce both bugs and the technical debt that accumulates when known problems are allowed to remain.

“If you know a failure is there, there’s no point in postponing the decision to fix. You have to fix it immediately.” – Muli Berry

Look at the Entire System

Optimising individual teams or components doesn’t necessarily optimise the complete software development process. Mooly argues for looking at the entire lifecycle to identify the real bottlenecks and the areas where changes will have the greatest effect.

That becomes increasingly important as software systems grow more complex. A change in one area can affect something elsewhere and introduce unexpected regressions. Automated testing helps catch those problems, but the testing process itself needs to evolve along with the systems being tested.

Code Example: Basic Structure for Automated Testing

# Example placeholder for automated test setupdef test_software_component(component):# Setup for testingsetup_component_environment(component)# Run the testresult = run_component_test(component)# Validate the resultsassert result == "Expected Outcome"# Function calltest_software_component("braking_system")

Catch Problems Early

The longer a bug remains in the system, the more difficult and expensive it can become to fix. Mooly argues for detecting problems as close as possible to the point where they are introduced, before other development starts building on top of them.

The principle applies whether a team works with Agile, Waterfall, or something in between. The methodology matters less than understanding where defects enter the process, identifying the weak points, and adapting the testing process accordingly.

Agile vs. Waterfall: Adapting Methodologies

While Muli asserts that the core principles of fixing bugs at their injection points apply across methodologies, whether agile or waterfall, it’s crucial to tailor processes to identify weak points and introduce changes that facilitate better outcomes.

Three Things to Take Away

1. Look at the stream of bugs, not just individual bugs. Recurring defects can tell you where the development process itself needs attention.

2. Experiment with the process. Make changes, measure the results, and keep adjusting the balance between development speed and stability.

3. Optimise the entire system. Focus on the weakest points in the software lifecycle rather than optimising individual teams, components, or silos..

If you’re fixing the same kind of bug for the fifth time, perhaps the bug isn’t the thing that needs fixing.