Moderation 101

chromatic talks about the overuse of patterns and design in software development. This highlights a problem the software industry seems to have – it just doesn’t understand moderation. It’s not only design that suffers from excessiveness, it’s processes too. Some people get so caught up in explicitly defining and then following a process that they spend more time on the process than actually getting things done. Worse still are the people who get so caught up in the process that they forget to check that it actually achieves the right thing. Of course, none of that should be taken to mean that all processes are bad, but in needs to be taken in moderation. This attitude that extreme programming takes of “if doing a bit of this is good, lets turn the dial all the way up to 11” is really crazy. Too much of anything is bad for you. You need unit tests and they need to cover your code well, but you don’t need 100% test coverage or you’ll just spend way too much time writing tests (not that extreme programming actually advocates 100% test coverage). Pair programming is another great idea that can be taken too far. There is a lot of code where it really helps to bounce ideas off of other people for, but there’s a lot of fairly mundane code that you should be able to write without help and still get it right first time. In those cases it’s a waste to have two people doing mundane work, you should just split up and work individually until you hit a problem that benefits from pair programming. Again, moderation. Anyway, with a thunderstorm coming I think I’ll blog in moderation and sign off now.