Welcome to MSDN Blogs Sign in | Join | Help
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.
Posted: Friday, August 17, 2007 2:20 PM by casper
Filed under:

Comments

Reeve Fritchman said:

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

# August 17, 2007 11:21 AM

casper said:

I think if you can encapsulate business logic or processes properly, even they can be 'good' code. It's not necessarily easy though :)

# August 20, 2007 2:06 AM
Leave a Comment

(required) 

(required) 

(optional)

(required) 

  
Enter Code Here: Required

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Page view tracker