Software development and the waterfall model

As mentioned, I recently read The Design of Design by Fred Brooks.

He covers a lot of ground, albeit not in any rigid fashion. As such, it is not a handbook, but more a collection of thoughts about the design process, most grounded in personal experience. Fred Brooks knows his stuff.

An interesting point he makes is that the waterfall model of software development is completely flawed and should be abandoned.

In short, the principle in the waterfall model is reason - good solid thinking: first we figure out all what's needed in a given system, then we figure out all aspects of how to build it, then we build it.

He has several arguments for why the model is flawed. One of the simple arguments is that it doesn't model how good designers work. Naturally, if you want everyone to follow a certain mode of operation, it would seem like a good idea to copy the mode followed by the good ones.

For me, the biggest flaw of the waterfall model and its companion, the big fixed-price project, is that it requires one to make the decisions up front where the uncertainty is greatest and the consequences of each decision most remote.

This shows up even in the earliest phases, e.g. when discussing whether to include a certain requirement or not. Inclusion may mean that the project will run over budget and schedule and produce a completely impractical never-used feature. However, the budget overrun may not even be visible in the design phase, but only show up late in development, and the futility of the feature may not show up until years after deployment where it is discovered accidentally that nobody uses it.

An important point in the book is that the design process is a learning experience, a process where one learns what's needed and what's possible. And what's elegant and what's good in the particular circumstances. I'd add that the same is true of the embodiment of the design, the code itself. Often people won't understand a system properly until they sit in front of it and have to start doing what they need to do. Deployment is always a learning experience. And similarly, it can be hard as a developer to assess the consequences of a paper design. When the code is written, maybe that fancy idea everybody liked beforehand isn't that hot afterall.

If one doesn't allow for learning, both for the receivers of the system and the people who deliver it, it's really difficult to get the software right.

By this thinking, the rational model becomes a bureaucratic way of delivering what might just turn out to be the wrong system.

Garden design

I recently read The Design of Design by Fred Brooks, the guy behind the mythical man month and the magical silver bullet debunking. I'll save further commentary on the book for now, but one of things he mentions is that rules sometimes help the designer because it sets some boundaries within which creativity can blossom.

I have a couple of rules for my little patch of a garden.


A passiflora growing outside in the summer

A first simple rule is that there shall be no grass. None at all. While lawns are nice and everything, it takes a lot of labour to keep a lawn, ideally it needs mowing at least once a week. Even then, unless you have the perfect growing spot for grass (plenty of sun and water), chances are it won't be a pretty one. This is compared to the other beds which I weed maybe two or three times a year while otherwise enjoying the flowers.

Also everybody has a lawn. Most don't look pretty. No fun at all.



Another rule is that there shall be as little uncovered ground as possible. Naked fertile soil is a highly unstable labour-requiring condition, nature will have its way. It also looks silly.



Yet another, less simple principle is that the garden must grow organically, chaotically, like nature, as opposed to being a tidy, trimmed show case of culture. As few straight lines as possible. Make no mistake, it's still designed in the sense that I exert control, it's not nature; if I didn't manipulate it heavily, it would turn into a shrubbery in a few years. But I'm attracted to idea of a green wilderness, to seeing things grow vigorously.

So I tend only to pull up the most annoying weed, the species that are hard to get rid of, and I let the decaying plants stay where they die (from a pull-up or otherwise). It's easy and it works well, most of it is gone when the season is over.

I try not to have too many of the same species in the same spot. Nature seldomly has 10 similar specimens right next to each other at exactly the same age. This also offers some protection against various pests.

And most of the plants I've bought are from seeds or small specimens from the local super markets. There's no overall plan to follow, hence I can satisfy sudden impulses without getting into trouble. And I don't mind having to wait to see the results, watching things grow and looking forward to the adult specimen is part of the joy. It's like buying yourself a gift that you cannot in any way unpack until a year or two after.

A side-effect of the wilderness idea is that my little patch has a lot of small visitors. Which is certainly something to be happy about. Sitting a summer day in the sun, with bees buzzing around collecting honey from the flowers one has put in place many months ago, removing weeds here and there, noticing details one has never seen before, discovering new species that have invaded the soil on their own. I can think of nothing more peaceful.




Of course, I'm learning from this approach. This year I'm beginning to think I need one more rule. Plants on the pathways must be cut down no matter how interesting they look, otherwise it gets too cumbersome to get around, and then I seldomly get to see the outermost corners.