aSPICE – Do Developers Really Hate It?

First Principles: Understanding Industry Needs

Before we jump to conclusions, let's reflect on first principles—the foundational ideas that shape how we approach software development. Different industries operate under different guiding paradigms, and these paradigms dictate the processes and methodologies best suited for delivering value.

Let’s explore this with a simple exercise.

What is the main driver in developing a software system for the banking industry?

Take a moment to think about it.

The core principle in banking software is data consistency. In this context, data represents money and value. Protecting this data's integrity is paramount. This principle influences how products are designed, tested, and deployed. It shapes team structures, qualifications, and even DevOps strategies. Essentially, it defines what is considered "good" or "bad" in product development for this industry.

Contrast this with the telecommunications industry. Here, service availability is king. Data consistency, while important, takes a backseat to ensuring the network is always up and running. This shifts the focus to infrastructure resilience and response times.

Now, consider the difference between a smartphone app and the firmware of a washing machine. Is the difference in programming languages or complexity? Not really. The distinction lies in the physical reality the firmware must respect. A washing machine must manage the electromechanical systems it controls. A simple coding error could burn out a motor or worse—physical systems demand real-time, fail-proof control.

Think about the contrast between the controller of an elevator and that of a washing machine. Both manage machines, but functional safety is a critical factor for elevators. A failure in an elevator system could be fatal. This safety requirement significantly influences how the software is designed, tested, and validated.

And what about the difference between developing software for a tram versus a car? While functional safety concerns are similar, the scale of production changes everything. Correcting a defect in 50 trams is vastly different from recalling 200,000 cars. The production scale introduces new challenges in quality assurance and risk management.

So, Do Developers Really Hate aSPICE?

I don't believe so. Developers understand the fundamental principles of the industries they serve and adapt accordingly. The frustration often stems not from aSPICE itself but from how it's implemented.

It’s important to consider who designs the processes you follow. Ideally, process owners—seasoned experts like top requirements engineers, architects, and testers—should define workflows. Have you ever challenged these processes? Or were they written by individuals lacking practical experience? This distinction is crucial.

aSPICE doesn’t dictate how you should achieve goals but what outcomes must be met. The method is up to you.

For example, is your DevOps pipeline streamlined and efficient, or are you still signing paper copies of Excel sheets? That’s not aSPICE’s fault—that's a decision made within your organization. aSPICE does not prescribe your toolchain or workflows. It requires deliverables but leaves the implementation strategy to you.

Balancing Compliance and Developer Needs

Whenever I speak with senior developers about the intentions behind aSPICE, they rarely dismiss it outright. They recognize the value of documenting code—not for compliance alone, but to benefit their future selves and teams. Many have experienced the nightmare of maintaining legacy code with poor or nonexistent documentation. Debugging such systems is frustrating and risky.

The real issue arises when compliance becomes a box-ticking exercise rather than a meaningful process improvement. When poorly designed processes hinder creativity and innovation, it’s understandable why developers push back. But this isn’t inherently aSPICE’s flaw—it’s a sign that internal processes need reevaluation.

A Call for Thoughtful Discussion

So, before echoing statements like "developers hate aSPICE," consider the source. Are you listening to voices of experience or those who speak without understanding? Seek out insights from developers who’ve successfully navigated compliance without sacrificing efficiency and innovation.

Let’s shift the conversation from blame to constructive critique. aSPICE is a tool—a framework. How we wield it makes all the difference.

Thank you,
Petr