Kata Seven: How'd I Do?

The last couple of kata have been programming challenges; let’s move back into mushier, people-oriented stuff this week.

This kata is about reading code critically—our own code. Here’s the challenge. Find a piece of code you wrote last year sometime. It should be a decent sized chunk, perhaps 500 to 1,000 lines long. Pick code which isn’t still fresh in your mind.

Now we need to do some acting. Read through this code three times. Each time through, pretend something different. Each time, jot down notes on the stuff you find.

• The first time through, pretend that the person who wrote this code is the best programmer you know. Look for all the examples of great code in the program.
• The second time through, pretend that the person who wrote this code is the worst programmer you know. Look for all the examples of horrible code and bad design.
• The third (and last) time though, pretend that you’ve been told that this code contains serious bugs, and that the client is going to sue you to bankruptcy unless you fix them. Look for every potential bug in the code.

Now look at the notes you made. What is the nature of the good stuff you found? Would you find similar good stuff in the code you’re writing today. What about the bad stuff; are similar pieces of code sneaking in to your current code too. And finally, did you find any bugs in the old code? If so, are any of them things that that you’d want to fix now that you’ve found them. Are any of them systematic errors that you might still be making today?

Moving Forward By Looking Back

Perhaps you’re not like me, but whenever I try this exercise I find things that pleasantly surprise me and things that make me cringe in embarrassment. I find the occasional serious bug (along with more frequent less but serious issues). So I try to make a point of looking back at my code fairly frequently.

However, doing this six months after you write code is not the best way of developing good software today. So the underlying challenge of this kata is this: how can we get into the habit of critically reviewing the code that we write, as we write it? And can we use the techniques of reading code with different expectations (good coder, bad coder, and bug hunt) when we’re reviewing our colleagues code?

Comments

[Kiranpulsar2007]

hi sir am kiran from india

i finished my masters of computer applications in the year 2009 still am not got any job in software development ...am very weak in programming language and coding skills how can i improve my coding skills and programming skills

please suggest me to improve my carrer in coding skills

please kindly reply to me

kiranpulsar2007@gmail.com

[Dave Aronson]

I once read something somewhat like:

- The novice comments nothing.
- The apprentice comments everything.
- The journeyman comments why he did things that way.
- The master comments why he DIDN'T do things ANOTHER way.

[Dave Thomas]

Harvey:

I personally write comments (and hope to see comments in the code I read) that describe why non-obvious code is the way it is. I expect to see the code itself to be clear enough to document what it does.

The exception is with public APIs, where I use comments to document the interface, and tools to extract and format those comments into generally usable (say) HTML pages.

Dave

[Harvey Flaisher]

Hello Dave:

I hope I am posting this in the right place. What is your opinion on in-code comments. I have done this all my career and cant imagine anyone discouraging it. Yet, on my current project, there is a Java developer who discourages this.

Your opinion?