Developing software must be done using lean and agile software process models, and the suggestion to use (the so-called) waterfall or rich models is overcomplicated things (and yes, RUP falls into this category) – just pure evil!
Don’t get me wrong – keep it simple (KIS, not KISS) is an important principle, and I do think models to aid us develop better software is equally important. It’s just the current debate resembles that of the ‘programming language insert-the-name-of-your-favourite-here is better because of feature x which insert-the-name-of-your-second-favourite-language-here does have’ debate…
Here’s why (opinion) . . .
Team Structure and Process Model: Conway’s ‘law’ articulated the important link between team structure and architecture. He’s idea was that the software (communication) structure will mirror the communication structure of your team. Subsequent research did find a correlation between two [PDF, 4.9Mb], so although it is unlikely to be the only influence (e.g., cause) – there is an influence. But this is an unlikely topic in software process models.
Why is that? And no, Pair Programming is not an example.
Monolithic Software Processes: Why do we have models that look like applications we designed back in the 80’s or 90’s? Modularity is a good idea for software, but our approach to software process models seems to be that of a single, monolithic, one size fit all model? There isn’t (explicit) support to modularise the model with elements from other models to fit your unique project (also related to above point).
Some guidance is better than no guidance: Yes, the wrong guidance is probably worse, but if people have gone through the hassle of defining a process, then there is probably some good in there – assuming application to the correct context. Lean is, by definition, about leaving stuff out, but wouldn’t it be better to guide people on how to leave stuff out rather than trying to figure it out for them (without any knowledge of their project)?What if you took out what some, although not all, need? You leave them with no guidance…
The problem with rich, waterfall, complex (whatever) models is not complexity, but not knowing what to leave out in what situation – and therefore killing the project by doing the wrong things (leaving out the wrong parts) or over doing it (not leaving out enough). And by religiously promoting a model as the model, you scare people from tailoring it to suit their particular needs.
How many process model has explicit support for tailoring? Not many…
Simple is the tomorrow’s complex: There are two forces in action here: 1) people like ‘simple’, because it is easier to understand and apply, and 2) people generally like to help, hence they start to elaborate on ‘simple’ and over time ‘simple’ becomes ‘complex’.
Dr. Winston W. Rovce’s paper titled “Managing the development of large software systems” is by some referenced as the ‘original’ source for what people might generally know as the ‘waterfall method’ (probably due to his figure 2 and call for extensive documentation).But reading the paper, it seems to me that Winston’s proposal is relatively simple, (somewhat) iterative and neither heavy or complicated. Maybe it is just (my guess) that the ‘waterfall method’ has evolved (through added guidance) and mutated (due to misunderstandings) into this rigid, heavy, slow process it’s perceived to be today.
Yet process model ‘designers’ rarely consider, how people should extend their model as part of applying it – why not?
In summary: We have plenty of software process models – some great, some not so. But we need more about how to apply the models, how to customise them to each individual project, and how to modularise to avoid the ‘simple today, complex tomorrow’ anti-pattern.
Until then… yawn….