Agile 2007 - Design sense

  • Article

Yesterday afternoon I attended a workshop held by Michael Feathers and Emmanuel Gaillot called 'Design Sense - Can We Teach Deep Design Skill With Perceptual Examples?' The aim was to see if, after developing for many years, we gain the ability to sense if code is good or bad just by glancing at it (the theory comes from Malcolm Gladwell's Blink ). If it's true that we gain this ability over time, then perhaps we can find some way of sharing it with beginning developers.

In groups of eight or so, we went through tons of small code snippets and had to quickly rate whether we thought they were examples of good or bad code. The snippets were in different programming and spoken languages - some, like this one below, didn't even look like code.

 0g:84*-!#@_801p0>_#":2%86*+\2/01g1-:01p0\#"_$$,,,,,1+

(It's actually Befunge)

I wouldn't say we reached any definite conclusions, but there were a few points raised that I found interesting:

  • Pain is the best teacher. If you have to suffer through maintaining poorly written code that you or someone else wrote, you will probably want to write better code in the future.
  • Bombarding junior developers with examples of good and bad code is a possible solution. Think of the opposite of Worse Than Failure. (Apparently this method is how vets are taught to differentiate between smart cows and dumb ones.)
  • Counter to the previous point, it doesn't matter how much you show or tell someone something - if they don't experience it themselves, they'll never truly learn it.
  • Sometimes there are physical constraints on writing 'proper' code. One individual pointed out that if you wrote tons of small classes (as we normally end up with for EDD code) it would very difficult to maintain in VB6 because the tool support is just not there.
  • Perhaps an obvious point, but worth stating anyway: defining whether code is 'good' or 'bad' is extremely difficult without context.
  • Sometimes you need to write 'bad' or 'ugly' code to hide some abstraction away so that the rest of your code can look 'good' or be more readable.