Automotive is a specific domain, where software development differs greatly from other fields. I have worked in many IT projects – mobile phones, desktop applications and tooling, backend services, web frontend and other – but none of these domains have put so high attention to the software development processes and quality. Now, after more than 5 years in automotive industry, I perfectly understand the reasons for such an approach. But what should be a blessing for the software can become a curse for the programmer. I bet every developer has complained about automotive processes. Hours spent on completing tables, polishing documentation or static code analysis after adding just a few lines of code. It can effectively discourage even the biggest passionate – especially in the absence of understanding the meaning of the tasks performed. If someone does not see the sense of what they do, then how can they work effectively and be satisfied with their work?
I believe that understanding the essence of processes in an automotive project is the basis for effective work. Why should each customer requirement be documented, versioned, and its source described? Is it really needed to make a reference to the requirements and design specification in the source code? What is the point of describing a unit test and linking it to the relevant requirements and architectural aspects? Knowing the answers to these questions significantly improves the quality of work performed, allows you to detect irregularities and improve not only the product, but also related processes. The goals of ASPICE, ISO 26262 or UNECE transport regulations become understandable and meaningful. Of course, processes make sense when they are properly defined and implemented.
Explaining processes in software development in the automotive industry is a broad subject. I am not going to discuss it in this post. Let me just mention the lifecycle of a car, which lasts at least several years. The software must be maintained all this time, challenges related to security and safety may force changes at a very mature stage. Even the creator of the code would have a hard time to recall the requirements and design after many years, not to mention a fresh team member. And this is just one of many reasons for such rigorous processes and requirements for software in the automotive industry.