DumbDev -- eight rules for dumb development

So often, we’ve been encouraged to be smart in our development. “Work smarter not harder!” say the encouraging posters. But the desire to be smart, and be seen to be smart, is hurting. The design suffers, the code suffers, and it’s hard to recruit developers smart enough to cope with the problems caused.

In this talk, I’m proposing an alternative to being smart: DumbDev. Let’s use our brains for enjoyable, interesting things, rather than wrestling with code written for smart developers.

So what do I mean by dumb?

Well, I don’t mean ‘ignorant’. A clever person can be ignorant of some important information, and learn it. With ignorance, there is hope. I’m also not talking about its opposite, ‘stupidity’. This occurs when someone is given the information or advice, and chooses to ignore it. Dumb isn’t stupid. Nor is it silent, as in someone who can’t speak.

Instead, the picture I have is of one of the early computers: very small RAM, disk space measured in KB, and a woefully inadequate CPU. In other words, slow, with very little working memory and limited persistent storage. Hey, this describes my brain – and I realise that’s an asset! I will write better software if I take this into account.

Here’s the first DumbDev rule, putting a sensible limit on complexity:

1. All diagrams must fit on a Noughts and Crosses (Tic-tac-toe) board.

One central class/concept and up to eight things linked. Larger structures need to be subdivided.