Agile 2007 - Design sense

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.

Comments

• Anonymous
  August 17, 2007
  I can understand the requirement to write "bad" code.  From a business application standpoint, soft coding is "good" but at some point we need to know that "Prepaid" means bill one party and "Collect" means bill the other party.  When application code decomposes down to fundamental business processes, you'll often see "bad" code.When I'm writing "bad", I follow the LOAP technique.  Using "Lipstick On A Pig", I strive to make my "worst" code my "best looking", probably out of a misplaced sense of guilt ('cause we Episcopalians don't feel guilty about anything else) and a hope that I'll brainstorm a better way later on.-rf
• Anonymous
  August 19, 2007
  I think if you can encapsulate business logic or processes properly, even they can be 'good' code. It's not necessarily easy though :)