John D. Mitchell's Blog

Code Naked

Finding yourself naked, in public, is a dream/nightmare that many people have. It could just be me but when I was first starting to program, I had a nightmare that not only was I coding naked but my code was naked, too. Partly in response to that, I became much more diligent about writing excellent code so that I'd never be embarrassed by my software.

Over the years, I've joked with various people that I "code naked" but most folks stop at the (all too frightening) image of me coding while naked. Alas, I've never thought about a more palatable phrase enough to come up with anything worth mentioning. Various industries like to use the term transparency but methinks that's too opaque and wishy-washy.

A student of Bob Koss comes to the rescue with the term Refrigerator Code:

It's code that you’re so proud of that you want to take it home and hang it on the refrigerator, right alongside of your children’s drawings.

On the other hand, one of the underlying reasons of Why Software Sucks is the fact that most software written is really what I call Toilet Code:

It's code that's so mediocre that when somebody encounters it, they just want to flush it down the toilet.

Comments

• :-)
  Maybe that is the reason why so many are scared of the XP practice of "Collective ownership", because they will be exposed in their shame.
  Kind of reminds me of the "Open Kimono" style of management from "Peopleware".

  Posted by: tobega on November 18, 2005 at 01:44 AM

• Collective ownership and "Open Kimono" are quite different. A dirty public park restroom is an example of collective ownership. Nobody in particular "owns" it so it stays dirty.

  "Open Kimono" implies transparency. Consider a book author. There is ownership. The book and the author are clearly tied together and the relationship and the book's text is transparent. Who feels more shame, the author of a poor book or one of many authors of a poor wiki page? It's hard to know who wrote something on a wiki page just as it's hard to know who wrote the bad code in a "collectively owned" code base.
  

  Posted by: tcowan on November 18, 2005 at 11:25 AM

• Hmm, but collective ownership works in a small enough group, capable of collective pride, quite different from your public restroom or the anonymous authorship of a wiki page. Besides, the cvs record clearly shows who did what.

  Posted by: tobega on November 18, 2005 at 03:01 PM

• Collective Ownership isn't "Public restrom" code. Not even close. However, sometimes when you try to do collective ownership, you end up doing no ownership, which is bad. This is a failed attempt. (So achiving Collective Ownership is always a good thing, but trying collective ownership is risky, because the failure mode is not so nice).

  About Naked/Refrigerator code: Has anyone considered having a (long running) competition at their respective places of work for the best piece of code (to be put up on the wall next to the coffee maker). Is that a stupid idea, or could it work?

  Posted by: jhannes on November 19, 2005 at 07:15 AM

• Thanks for that mental picture John. Bleach... I need bleach for the brain!

  On the collective ownership thing - something that I found worked very well (as in, project vastly exceeded expectations, ie it came in early and under budget which was a good thing since it was thought it would be a loss leader) was to divide up the functional areas of the program. Have well defined interfaces (literally interfaces) and make sure that everyone knows what their bit needs to do. Assign the 'conductor' or 'coordinator' to the most experienced programmer. (That person will also need to write good coarse grained unit tests so you can track down whose code has broken if something isn't working).

  In that case it was me and a bunch of DBAs being retrained as Java programmers... and it was in production for over three years with no bugs found last time I talked to them.

  In this case, where there was a disparity of skills, collective code ownership wouldn't have worked. (NB: do not confuse skills with talent or ability, just because they didn't know Java doesn't mean they were stupid). One of the advantages of this, is that when you sit down with them to help them out, you have a good idea of what it is that they're trying to achieve, and also you can hook up 'test harnesses' to whatever their top level object is (the thing which implements 'their' interface), and then you have a pretty good idea of whether it is meeting expectations, and if not you can look at stack traces to find where things are going wrong.

  Where the level of experience is much closer, I still prefer individual ownership of code, since I find that in general I am much more rigorous in my testing than most of the other programmers I've worked with. While that sounds kind of anti-social, keep in mind that I have a healthy paranoia and distrust of *everyone's* code, including my own. Even TDD followers do not measure up to my standards (I find they tend to have huge 'blind spots' - especially common is that if all the unit tests run, they won't even bother firing up the app... it is like looking at a pile of toothpicks, checking that each one is indeed made out of wood, and then making the assumption that they do actually make a fully functional table...)
  

  Posted by: rickcarson on November 20, 2005 at 06:43 PM

• Hi John.

  This is Florence from TER. Please send your current email address to tang_fy@mercer.edu as www.non.net does not appear to be working.

  Thank you.

  Florence

  Posted by: tang_fy on November 21, 2005 at 08:42 AM

• Yeah, "open kimono" is focused on transparency. That goes well with this quote about pair-programming. :-)

  
  I find that "collective code ownership" is a confusing term because pretty much everybody has different notions of what "collective" and "ownership" mean -- particularly in terms of their implications. "Team stewardship" is certainly a better term but, alas, that seems to be a bit too far out there for many programmers, IME.

  
  An apt analogy for team stewardship is that of a house being shared by a bunch of college roommates. Yeah, I know it's another scary image but it fits so perfectly. Finding roommates, common areas (kitchen, living room, etc.), shared but private areas (bathrooms), private areas (bedrooms), scheduling (getting lucky signs, cramming for tests vs. party nights, etc.), conventions (clean up your own mess, taking turns vacuuming, etc.), paying the rent, mutual aid (homework, rides, answering the phone so I can avoid that stalker chick, etc.), etc. There's a lot of different styles that people try and different styles work better for different groups of people.
  

  Posted by: johnm on November 23, 2005 at 11:15 AM

• 
  Collective ownership doesn't work, with countries or code. Collective ownership was tried at a national level - it is called "Communism". Communism in its true form, beyond North Korea, is now globally dead because it was a failure. The failure of Communism is evident former governments such as in East Germany and the former U.S.S.R. China quickly speeds away from Communism towards the almighty dollar. Did your roomates ALWAYS clean up exactly on schedule, or did you have to clean up for them, in college?

  Collective ownership applied to source code ends in "Well, someone has to fix it", and it eventually gets assigned to one or a few individuals. The individuals assigned do the least amount of work possible to fix the problem, as they have other work they DO have ownership of. The invidiuals are also uninspired to make that unowned code the best it could be, with refactors, formatting, documentation, & performence testing.

  Does work get done? Yes, works get done in collective and non-collective ownership. But work gets done faster when there is clear ownership, because everyone knows who is responsible. In unclear ownership, the buck gets passed over and over - until there finally becomes clear ownership, or an expert resource upon that code. Incentive drives excellence, be it through rewards (good job on that code, here's a bonus!) or fear (if you don't fix it, we'll get someone to replace you). Lack of incentive spawns laziness - such as lazy wheat farmers in the former U.S.S.R. Sure, no pay works in Star Trek - but that's fiction, not reality.

  "Refrigerator Code" is a good term for code you should be proud to show your peers, or others who use your APIs or interfaces. The code will stand up in peer reviews, and others will give you the nod of approval after viewing your code. There's nothing we like better than to smile and say "This is a good piece of work" when we look at internals.
  

  Posted by: phlogistic on November 23, 2005 at 12:28 PM

• Collective ownership doesn't work, with countries or code.

  That's a great example of why the term "collective code ownership" doesn't work. It's way too easy for people to read all sorts of things into it that the originators never intended.

  Responsibility is another loaded term. Alas, it's usually used for blame management rather than real response and resolution.

  Posted by: johnm on November 23, 2005 at 01:47 PM

• Has anyone considered having a (long running) competition at their respective places of work for the best piece of code (to be put up on the wall next to the coffee maker). Is that a stupid idea, or could it work?

  In terms of team management, I'm not big on that type of formal competition. Perhaps I've just seen too many of them devolve into ego-driven wastes of time.

  It can be helpful to have a "cool hacks" section on a wiki and/or category in a developer's blog to share the love.

  Of course, I think the converse is also good -- a "toilet code" section/category that highlights examples of what not to do. I hope it's obvious that the submitters of these should usually be the person who originally wrote the crappy code. For example, at a company I worked at a long time ago, in e.g., the commit email message explaining a check-in fixing some crappy code that we had previously written, we'd sign with e.g., "John <-CurDkHdPtr".

  As I've mentioned before, I quite like having a section of a project wiki for "orphaned code". I.e., code that does something useful but isn't used (anymore) in the project.
  

  Posted by: johnm on November 23, 2005 at 02:04 PM

• E.g. the commit email message explaining a check-in fixing some crappy code that we had previously written, we'd sign with e.g., "John

  Hi johnm. Good comments. There's just one thing I am wondering about: "CurDkHdPtr"? What does that mean?

  Posted by: jhannes on December 04, 2005 at 01:34 PM

• jhannes, since this site is supposed to stay readable at work, let's say that you can think of it as a "hungarian notation" for an impolite Amercian phrase. The real point of that being that we would confess our sin to the group and call ourselves an idiot rather than running around calling each other idiots. That's the difference between taking responsibility and blaming others.

  Posted by: johnm on December 05, 2005 at 09:41 AM

This work is licensed under a Creative Commons License.