February 21, 2007

...Learn TDD with Codemanship

How To Win Design Arguments

If you're a software developer, and especially if you've drawn the short straw we call "software architect", you'll spend much of your time arguing with other people about the design of the system you're working on.

"Touch my code and you're dead"

Software design is like cat pee. Cat's mark their territory by peeing on it, so when other cats come along they can smell that it belongs to someone already. Developers like to "pee" on the code to mark out their territory - and this means making their mark on the design. This is why design is such a contentious issue: it's a matter of territory and ownership. If Sam says we should use Model-View-Controller and Jim says we should use Model-View-Presenter, and Sam wins the argument, then we end up building Sam's design, and it ends up effectively as Sam's code - even if he didn't write it himself.

This is why developers usually refuse to implement design models exactly as they're specified - it's like letting a big cat pee all over you.

Therefore, most design arguments are really nothing more than intellectual pissing contests, and the protagonists neither know nor care if what they're arguing for is a better design, just as long as it's their design. I know - I've done it.

There are all sorts of strategies for winning design arguments - including shouting, violence and blackmail. I don't condone any of those, of course. Instead, I prefer to come armed with solid theory, years of practical experience, and - most importantly - evidence to support my arguments.

Most design decisions come to down to choices that effect design quality in one or more ways. Putting a line of code in one class might create more inter-modular dependencies than putting it in another, for example. Putting a class in one package might make it more unstable. Calling a variable one thing might make it harder to understand than calling it another.

For most design decisions, there's at least one underlying design principle we can call on to guide in evaluating its impact on quality. And if we can firmly establish a link between quality and commercial factors like cost, productivity and value, then we have created a virtuous circle in which we can relate all kinds of design choices to the bottom line of a project.

For a guide to object oriented design principles and design quality metrics, visit the OO metrics page. This is stuff that every developer should know, and it should help you articulate and justify your design choices the next time the fur flies at the whiteboard.

Posted 15 years, 1 month ago on February 21, 2007