My recent post on usage of waterfall caused some stir and expectedly so. One of its outcomes was an interesting discussion on Twitter with Markus Andrezak followed by his comment under the post. As I promised to continue discussion on the blog, here is a follow-up.
Markus points that there’s no point in resigning from using method which is superior in terms of building software, period. What more, as I pointed out that using waterfall could help to decrease cost in discussed case, Markus question was: how the hell larger batch sizes could do so? Well, that’s not exactly the wording he used, but that’s what he meant.
I should have expected that. There are a couple of things. First, to some point I wasn’t precise when I used the infamous W-word. I mean, my idea wasn’t to build the whole damn thing in one batch. Actually I didn’t think much about the way development phase should be organized in. My point about using waterfall was more about having isolated analysis, development and acceptance test phases separated with formalized milestones, accepted by the customer. This way the vendor doesn’t start building anything until the whole app (part of the app actually) is defined. Then, after it is built it is verified against specs and not against emergent requirements.
Second, and this should have been stated more clearly, for me using waterfall in this case was more of a way of fixing broken vendor-client relationship than a way of fixing development process, which wasn’t broken in the first place by the way.
OK, this requires a bit more elaboration, I know. Here’s more of a context. In this case vendor-client relationship is kind of long and big history. The discussed project is tiny, teeny part of it. For both sides it isn’t an option to crush a lance on such project. It also means going away from the project isn’t considered as a feasible solution. The project is fixed-price and the price is not going to change even by a penny. The scope was defined very vaguely and with no details whatsoever. Folks on client’s side naturally want as much as possible, even though they don’t precisely know how the app should look like. For whatever reasons they don’t want to, or can’t, be engaged in development process on the fly – they don’t verify biweekly demos, etc. They just want to see final prototype.
In other words, being on client’s side I would eagerly treat every delivered version of software as a prototype, see what is nice and what is not and then define requirements on the fly. At the same time I would probably enhance my domain knowledge so I can better answer what exactly I do need.
It would have basically worked great. It would have if it had been a classic agile contract where cost is based on real vendor’s effort. Unfortunately it is not.
If the money wasn’t a problem at all I would definitely advise using agile methods as with vague requirements and changing scope it is kind of obvious choice. The problem is with such approach cost sort of skyrockets.
And this is where we come back to good, old, hated waterfall which tells us to fix the previous phase before we start the next one. Fix the analysis/design before rushing to build anything. Yes, I do know that this method doesn’t end up building the best possible app. Yes, I do know that it leaves the problem of vague requirements solved suboptimal way, e.g. we define what done means at the beginning when we have the most limited knowledge. However, considering that walking away is not an option for any of sides, the best option is trying to make it win-win.
What does win-win mean in this situation? Well, it means reasonably good app within given cost. It means defining what is to be built, estimating the effort, cutting corners when needed or adding stuff when possible, fixing all those and building the thing according to specs. And then, verifying the app against specs relentlessly.
The goal isn’t to build the app which solves the problem in the optimal way, or to build the optimal app, or to build the app optimal way. It’s not the software development problem. It is relationship issue.
Now, I don’t say anything about the software development itself. Actually, despite the situation I would advise small batches even though with detailed specs and no expected changes bigger batches aren’t that painful. This part however will be neither seen nor appreciated by the client. It is kind of inside baseball thing from a perspective of the whole problem.
OK, this time I hope a long version of my explanation does a better work but, same as the last time, I’m ready for discussion.
OK, just joking…