It has recently come to my attention that even today there are still enterprises that standardise on the so called “V model” for their software development work (from requirements writing to testing). In this article I will explain why this is a bad idea, even looking through some very forgiving lenses.
What Is the V model?
The V model (also explained here) is an extension of the sequential (“waterfall”) model of software development. Instead of showing the sequence of work tasks as a straight line as in the waterfall model, both ends of the process chain are bent upwards to signify higher levels of abstraction, different roles, and a correspondence between requirements, designs and tests. Looks pretty logical, right?
What Is Wrong with the V Model?
Historically, the V model was made with the waterfall model of software development in mind. It assumes long time-frames with phases progressing in an ordered fashion from requirements analysis to system design to programmering, and finally to testing. All descriptions of the V model talk about each node as a “phase”. Phases have more or less been removed from software development today, displaced by iterative or continuous models.
Philosophically, the V model assumes any problem can be solved by breaking it down into smaller and smaller pieces. This is the analytic view of any engineer. When the V model was created, most programmers were engineers and software engineering was in vogue. This idea is sadly flawed. First of all, not all problems can or should be solved this way. For example, any form of modelling or design job is really an iterative process of gradually discovering better (more useful) solutions. There is really no right or wrong. A top-down, divide-and-conquer attack is great for mathematics and engineering; less so for design. Secondly, only a minority of programmers are engineers today and they solve problems very far from engineering.
The V model implies an ordered sequence of steps, which is hard to reconcile with the daily realities of software development. Obviously, the person who designed the V model wanted development to occur that way because it appeals to a mind who likes order. But saying it is so does not change reality – it only misleads. Studies have shown how experts switch quickly between understanding the problem (analysis) and fleshing out a solution (design).
The V model divides responsibility strictly into roles, which creates waste. For example, the requirements analysis is performed by a business analyst or similar, the system design by an architect, and so on. This increases the divide between people instead of promoting collaboration. These last decades, there has been an increased understanding that to get good results, we have to work together. By grooming specialists with narrow responsibilities we will get more hand-overs, more misunderstandings, and more rework.
The V model is document-driven. It dictates that each development phase to the left result in some form of description, which can be used to design verification tests, which are then performed at the end, on the right-hand side of the model. We have gained the understanding that written communication is not always best. It has its advantages, but when you really want to spread a common understanding, face-to-face communication is superior.
The V model puts way too much time between specification and verification. In the V model, testing that requirements have been satisfied occurs quite some time after the requirements were fixed. Even unit testing is separated from programming of the unit, typically performed by another person than the developer. However, the sooner we can verify something, the faster we get feedback. In a process using feedback, that means quicker response times and quicker corrections. The last 15 years software developers have even managed to move the feedback before the module being developed and in that ingenious step merged verification and specification into one.
The V model puts far too much weight on verification testing (finding and removing defects at the end) and not nearly enough weight (none, to be frank) on preventing errors in the first place. Quality studies have shown that teams with great quality skills avoid many of the defects that end up costing a lot more if found at the verification stage. Examples of practices that promote this are pairing, specification-by-example, and test-driven development. There is a quote from Edwards Deming related to this:
“As Harold S. Dodge said many years ago, ‘You cannot inspect quality into a product.’ The quality is there or it isn’t by the time it’s inspected.”
Finally, the V model is too limited in scope. It assumes there are some omniscient people on one end with a perfect view of what the customers will need and those assumptions are never verified. We only verify that the requirements, as described, are satisfied, which is clearly not the same thing. The growing awareness of the role of the customer (or user) in product development has shown us that leaving them out of the loop is not a clever idea. We have realised, from user-centred design and user experience fields, that business value appears when someone actually uses a feature, never before that. From Toyota Production System we have the “pull” model, where customers are though of as pulling new products out of the factory. There is even talk among management consultants that we are entering a new era of “consumer capitalism“. The buyer is in control and companies that delight the customers will be successful. To summarize, we need continuous feedback from our customers and stakeholders.
Re-interpretation of the V Model
Now, there are probably readers who feel I have been too harsh on the V model in this article. They will claim that a modern interpretation of the V model is to read the length of one ‘V’ as one iteration instead of a project. Then, surely, the V model would make sense even in agile projects? My response to this would be an emphatic “NO“. Agile iterations are not small waterfalls. Activities of different type happen in parallel, dynamically, when needed. Furthermore, most of the other objections above would still hold.
But what if we narrowed it down even further? What if one ‘V’ just represented development of a single feature? A few days work, maybe. Would that solve the problem? Sadly, still no. There are still no feedback loops. The model still communicates an unrealistic degree of order. It still emphasises inspecting quality after-the-fact. It is still limited and heavy on work documentation. It still promotes specialists with a limited view of the whole process.
Let’s face it: The V model is not suitable for product development and it never really was. Why try to cram modern thinking into an obsolete model? Why not use some other model instead? It is time to put the V model to rest.
What Would a Better Model Look Like?
First of all, a new model would be contextual, meaning it depends on the situation. Like many have said before me, there are no “best practices” in product development. Therefore, I cannot give you a model that will work for you. Only you can do that. But what I can do is present some ideas, which I think could be identifiable in a process development model in harmony with current thinking.
I believe a more useful product development model would:
- …include users and other stakeholders, starting from their needs all the way to actual use of features and back again.
- …focus on optimizing flow of value through the process instead of having defined roles and steps.
- …de-emphasize phases, instead have work cycles with feedback to gradually refine the solution.
- …de-emphasize specialist roles and boundaries between them, instead focusing on teams working to optimise the whole.
- …de-emphasize documentation as a means of communication, instead relying on natural collaboration between team members.
- …remove the artificial boundary between requirements and tests. Specification by example shows us how to specify software in a human-friendly yet automatable manner, using examples to guide us.
- ..remove the artificial boundary between software design and tests. TDD shows us how to design software incrementally, with quality built-in, using tests to guide us.