We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

DumbDev -- eight rules for dumb development

Formal Metadata

Title
DumbDev -- eight rules for dumb development
Title of Series
Part Number
146
Number of Parts
173
Author
License
CC Attribution - NonCommercial - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language
Production PlaceBilbao, Euskadi, Spain

Content Metadata

Subject Area
Genre
Abstract
Rob Collins - 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. So, I'm a **_DumbDev_**, which means I can't hold in my mind the infamous [Plone Site class hierarchy] (see [Michele Simionato's article]). 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**. 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.
Keywords