Software engineering: from the traditional V cycle to eXtreme programming
The picture on your right hand shows how software are most of the time developed. This model is called the V cycle or V Software Systems Engineering Process.
Like most project management methodologies, the V-cycle was adapted one day from construction industry practices. Indeed, the construction business is 5000 years old and hence much more mature than the 30-year old software industry.
Although the V software engineering process is a proven methodology, my experience working for/with software start-ups in Israel and Spain as a functional project manager & business development analyst convinced me that using the V-cycle methodology implies:
- too much of an early-staged design (re-engineering is costly); the Society we live in goes too fast and nobody can afford to freeze one’s specifications too early.
- the end product is actually a ‘product end’. In other words, it’s hard to make your piece of software evolve and come up with new releases at a reasonable price.
- it suffers many bugs (there is one and just one delivery date) and the cost of non-quality’s pretty high.
However, I now study with software engineers and it appears that the V software engineering cycle applies well to industrial environments, embedded software, and huge outsourcing projects on the condition that the two teams (on-site & remote) know each other well.
But, as inexperienced as I am, I can tell the V cycle should never, ever used as a framework in fast-growing or -changing environments. In the latter cases, I recommend you use eXtreme programming methods.
EXtreme programming works best with small development teams in nascent & disruptive industries (Web 2.0, SOA, Web Services) in which the actual needs are yet to be defined accurately (that may also mean that the client is dumb or that your boss doesn’t know what (s)he wants).
This is how I’d define eXtreme programming: automatized unit tests, develop in pairs (2 software developers hand-in-hand), interact & iterate.
At iMarket in Israel, our software developers Raphaël Benzekri & Radi Isakharov did a fantastic job working physically close to each other, communicating constantly with the CEO (who basically behaved as a client), going back & forth constantly, and coming to me (functional PM) for troubleshooting, end-of-pipeline tests, budgeting & new idea generation & outside vendors integration (we were working with a graphic designer & a mobile communication services provider). Raphaël & Radi ended up devising an entire 80,000-lines-of-code-strong e-Commerce software in just 5 months using eXtreme programming methods. Working in pairs, I realized, is fast and is an insurance in itself of quality programming: when a method was implemented by, say, Radi, it was immediatly challenged by Raphaël, and so on and so forth. Both could share knowledge and lessons, and the entire team (there were 6 full-time people at that time in the company) was consistent and satisfied with the advancement pace.
Just to repeat myself, this is how eXtreme programming works: client –> developers –> client –> developers –> client –> developers –> client –> … Unlike in V cycle programming environments, deliveries are frequent, implementation is on-going, team consistency’s extremely high (two software developers working hand in hand) and the software enjoys an embedded documentation.
I hope I made my point: heavy projects, administrative burden, structured client –> go for a V cycle-like methodology; enthusiastic young developers, disruptive industries or environments, absence of well-defined specs –> that’s a no brainer: go for eXtreme programming. For outsourced software development projects, consider Agile over eXtreme (for an interesting comparison of these two methodologies, take a look at this post on Benjamin Mitchell’s excellent software engineering blog).
Related posts:
- 2 resolutions for 2007: visit a cluster of innovation every year & brush up my programming skills
- 7 good software project management videocasts
- Microsoft IDEAS software startups web 2.0-style
- My call: software companies can't take off well in financial centers
- 12 non technical tips to design kick ass software architectures
.NET (C#), CIO, ERP, Education, Entrepreneurship, Friends, Internet, Israel, Microsoft, Organization, Outsourcing, Project Management, SME, Silicon Valley, Software, USA, Venture Capital, open-source, operations, user-generated content
I experimented V cycle in my last big company… To be short V cycle is for big company where quality process is a religion and where managers want to master everythink without having the capacity to understand anything.
In 1 word, V cycle kills innovation!
Thanks Pascal, you perfectly recapitulate what I meant before: V cycles are relevant for risk-adverse clients (actually they take more risks, but whatever) in slow-paced environments where INNOVATION, as you point out, doesn’t matter. Pascal, could you maybe share accurate examples of situation in which V cycle proved to be counter-effective? Many thanks in advance.
As a innovation minded guy, unfortunately, I could not help you to find good exemple of V-cycle application.
Pascal, I know that there’s no way you might be anything else than an innovation guy since you work with Hubert on the Geonimmo project. My question was that since you actually worked within a V cycle frame in a big company, you might have some stories to share with us.
No precise example to share but overall spirit… At the beginning when we had new ideas, new concepts, we give a try by coding it to see if the new ideas were relevant and to better study it. After V cycle storm, you no more have the right to do a code trial before going into deep documents writings, too much meetings, etc… By doing so, new ideas, proposals were simply no more present. But as it was the goal of the managements, on their side it was not an issue. But for me a society which does not innovate and doesn’t even allow innovation, will die soon… V cycle kills innovation except if you are using it carefully may-be
Pascal, thank you very much for sharing your valuable experience with us. This is great stuff: looking at the V cycle chart, there’s indeed no way anyone can come with a new idea once the deliverables are defined (usually very early).
It’s been a while since I studied anything like this, but don’t some of these models have feedback-loops allowing for changes up the ladder of development–It would seem pretty unrealistic, indeed stupid as you suggest, to do otherwise?
Not that with feedback a project is less likely to fail. In my opinion, no matter how well you plan out a project, it’s really the quality of the people involved that makes the difference. The better trained and experienced they are, the better they are with documentation, communication and precision, and, equally important, the quicker they can adapt and make changes.
A comment on the presentation of this post. I love the V-graph. Any chance on an extreme programming graph? A picture says more than a 1000 words
(Ah, here you go)
Thanks Vince, interesting chart on your link. And I agree: top people build top projects.
However, this is too easy. The best managers empower average people and foster their creativity and work ethics until great things are done too.
You’re right, my view is too simplistic. What I was trying to say is that most errors in programming will be human errors and having a qualitative staff prevents this to a degree.
About a manager hiring average people–you’ll have to remind me of the last time was you saw an advert for “have job for average person.”
Of course a good project structure will help, but the problem with the word “structure” is that it and “flexibility,” which I guess XP is all about, don’t mix very well.
In many cases (perhaps not XP) they seem like tools for managers to have a sense of control, something to report to their superiors and shareholders. Just my opinion of course..
The thing is, Vince, that top people are in short supply. So at some point, you need to train people.
Looking for programming support from a repsonsible company that can move fast in dveloping multiple areas simultaneously in a more expeditiocus and economical way to help frow our own system which has a lot of demands so we cannot do it all in-house.
Some good points here. However, I do not believe that the V-Cycle necessarily kills creativity. It is just that the creativity is at the high level and the functional design stages, rather than during the creation of the code (and I reckon that is why it gets criticised by software programmers). I think it is suitable where the coding of the system should be straightforward, and endless back and forths during that stage would just lengthen the duration of the stage and not add value.
I work in the safety critical automotive industry. Here V cycle rules supremely. We have legal requirements to maintain traceability from documentation through to code. We don’t like it any more than you guys, but it does the job perfectly.
Big corps producing big projects with full traceability (like aerospace, automotive etc) use tight coding restrictions and plenty of process to make sure things work.
I work in safety critical automotive industry (Rail transportation).
In the initial stage of implementing it is very tough to follow (cost and training).
But this helps for a lot to maintain high quality standards.
I have worked 10 years in the automotive industry in engine management systems and I think it’s where the V-cycle originated.
The core business there is upstream in the control strategies. That’s where companies differentiate and innovate. The software coding is just the execution. There are usually also several steps in the V-cycle, adding content at each step and allowing for minor modifications.
That being said, it is a heavy process, and I believe it would never work in a start up developing web based applications for instance.
If you want to see a few other models:
http://codebetter.com/blogs/raymond.lewallen/archive/2005/07/13/129114.aspx