Description
Rob Collins - DumbDev -- eight rules for dumb development [EuroPython 2015] [24 July 2015] [Bilbao, Euskadi, Spain]
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.
So, I'm a _DumbDev_, which means I can't hold in my mind the infamous [Plone Site class hierarchy][1] (see [Michele Simionato's article][2]). Rather than beat myself up about this, I can say, "Hold on, maybe deep inheritance is a bad idea..." There is some debate about the number of things we can think about simultaneously: it may be 7, 9, 5, 4 or even only 3. We can learn some tricks to appear to cope with more, but most of us can't easily do 38.
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._
There are seven further rules for me to explain in this talk. I will demonstrate the benefits of the _DumbDev_ approach, with good and bad examples. At the end of the presentation, I hope you will realise that you're a better developer than you thought at the start. The next time it takes you two hours to debug a simple exception, you'll know that it's not you. It's because the system wasn't written using _DumbDev_ rules.
Let's free our brains for more interesting things, like having ideas and solving problems.
Let's do _DumbDev_.
[1]: http://www.phyast.pitt.edu/~micheles/python/plone-hierarchy.png [2]: http://www.artima.com/weblogs/viewpost.jsp?thread=246341
