Have you ever pondered which waterfowl personifies best practices in modern automotive software development? A quick disclaimer before diving into this critical and pressing issue. I haven’t intentionally committed code to a repo destined for the shipping product in more than a few years. Today most of my code is destined for the internal financial tools repo. I suspect that some of my code is still in use in demos and examples that are packaged with the product. Alas the subversion history wasn’t migrated into git, so my name doesn’t show up when I run git blame. On the other hand, I constantly talk to our developers and our customer’s developers at least weekly. So I confidently claim to still have the pulse of the active practitioner. /end disclaimer.
So, why water fowl? and what do they have to do with automotive software development? Good questions, I’m glad you asked.
Automotive software, like most safety critical software, is subject to certification processes to ensure that software is fit for purpose and implemented correctly. Despite any and all griping by those who must make changes to achieve compliance, safety certification is a good thing. Even with certification, you can find articles highlighting software problems at companies such as Boeing, Toyota, and Jeep. On the whole operator error accounts for a much larger number of problems than errors in certified software. This simply tells us that there is still room for improvement in the certification process, not that it is worthless.
Software development methodologies
With the value of certification established, or at least alluded to, we next consider how development organizations go about the process of building the software so that it can be certified. To state the obvious, everyone building software for certification uses a formal process of some sort.
As there are almost as many formal processes as there are software developers, see the sidebar at the Wikipedia entry for Software Development for proof, stating any sort of generalization might seem impossible. To my eye all of the possibilities can be considered as either a heavyweight or lightweight process. Heavyweight processes are characterized by a high degree of regulation and planning while lightweight processes are iterative and incremental.
At this point many will point out that many government regulations, including both US and German, require heavyweight processes, often V-Model and thus claim that lightweight should necessarily be ignored. Others, many of whom were trained after the publication of the Agile Manifesto in 2001, claim that a lightweight or Agile methodology is the one true way. Since a picture is worth a thousand words, proponents of methodology have published images that try and capture the process such as the V-Model image or the Scrum Iteration Diagram or the most basic Development Spiral.
#/media/File:Scrum_process.svg){kind=link}
.svg){kind=link}
And now we finally get to waterfowl, I generally find the V-Model reminiscent of a flock of geese flying south.
Which methodology to use?
Now, some 600 words into the post, I can get to the point. Modern automotive software development methodologies don’t need to be an either/or proposition. The formal requirements, traceability from requirements to code, code to test, and test back to requirements found in the V-Model are clearly relevant for certification.
Look closely at that statement, requirement to code, code to test, and test back to requirements… that looks a lot like a cycle, loop, or iteration to me. Taking the next step, the V-Model Specification calls for creation of User Requirements, Functional Requirements, and Design specifications. These sound a lot like the Epic User Stories, User Stories, and development tasks found in an Agile Process. Further, both the V-Model and the Agile cycle require testing of every part of the code.
Sure the V-Model picture implies that you might not test until all development is done. But nothing in V-model that says you can’t test each part of the code as soon as it is done. I like to infer that you don’t need to delay the start of development until all specification is done. You only need to wait until the relevant part of the specification is complete. This sounds an awful lot like the incremental problem decomposition of the agile spiral.
Taken into practice I’ve seen teams apply the V-Model to each stage of the V-Model to enable earlier deliverables. Effectively these teams are reinventing the agile loop with somewhat straighter sides. Modern implementations of the V-Model are more accurately described as a V-Cycle, easily confused for an Agile process, with formalized requirements and traceability.
What does it all mean…
In conclusion then, the key to an effective modern automotive software development process when developing code for a certified environment is to remember that it’s all about waterfowl, not which sort. If you look closely you will probably notice that geese circle for a landing to eat and gulls use a V formation to fly long distance. You can use either as your mascot, just don’t get stuck on one part of the process. Further, you can listen to whatever sort of music you like while coding, not just English new wave synth-pop (see below for an explanation). So, get to it and write some good code! I’m off to crank up the stereo and see if I can find an outfit as appropriate as the Bruins wore to the Outdoor Game at Lake Tahoe.
