Comments and Footnotes

Will I ever stop railing on about comments? I don’t think so. As long as it’s possible to write code in a less than clear manner, people will always be compelled to explain their coding deficiencies. And I will always be compelled to resist.

As a writer, I try to ensure that the main text in a book or article is clear to the reader. Every rare once in a while (perhaps a couple dozen times in a book), I feel compelled to write extra information, something that supplements the text. I do so in the form of a footnote. The footnote provides non-essential information. It’s something that might help add some insights to what I just wrote, perhaps, or a humorous but otherwise distracting note.

My editors would never let me use footnotes to re-explain a passage of text. A coder attempting to salvage bad code with comments is like me adding footnotes to try and explain poorly written text. If the mainline text didn’t explain it well, why should a footnote explain it any better?

Footnotes and comments are ultimately a distraction. Ever try to read a book with footnotes on almost every page (and I’m not talking citations or references)? You may as well be reading two books, in some cases. As writers, we owe it to our readers write more clearly and to minimize these distractions.

 

Comments:

Excellent analogy Jeff.

Today I was asked what I think about assertThat for jUnit4 framework. It brings nothing more than a little bit more verbosity for tests, but won’t help people write better tests. Those , whom tests are of a poor readability and quality will remain the same with a new constructions, too.

Krakow

I visited a number of development teams (both C++ and Java) in Krakow, Poland over the prior two weeks. I also had an opportunity to speak at the Agile Poland Users Group. Overall, I enjoyed my visit, but was as always most thankful to return home. The Polish developers were mostly very good and interested in improving upon themselves. I learned a few things from them, and I hope they learned from me.

For many, not all, of the developers, I could offer only “the little things,” as they seemed to have solid basic knowledge. Mostly, I worked with them on improving the readability and maintainability of their tests. I think this refactoring of tests is where the real money proposition can start coming into play–until tests are of high quality, they will continue to be costly to maintain. I hope the developers took “the little things” to heart, because I think attention to them is what distinguishes a journeyman from a master.

Certification and the Agile Alliance

I attended a panel presentation, “To Certify or Not to Certify,” at Agile 2007 in Washington, D.C. The presenters included several esteemed members of the agile community, including (but not limited to!) Ron Jeffries, Michael Feathers, Mike Cohn, and Angela Martin. I thought the panelists offered some interesting but far from comprehensive thoughts on certification. The panel deliberately avoided “hot” or contentious questions, in favor of a subdued give-and-take on the topic.

What I heard was essentially this message: “certification is inevitable, so we should try to beat those other guys (whoever they are) to the punch.” Presumably, the interest would be to build good certification, so good that those greedy other guys don’t come up with poor certification. (The Agile Alliance issued a position paper on what they thought the value proposition was for certification; it can be found here.)

Shortly after the conference, I was invited to and joined an online action/discussion forum consisting of some of the aforementioned panel members. I asked for some goals for certification, thinking that there are many paths to many different kinds of certification. The first step toward any solution is knowing what the problems are, and how much of each problem you’re trying to solve.

If there is a discussion forum metaphor for blank stares, that’s what I got with my posts. A different action group formed, one where a decision was already made to build some sort of trust network (based on a notion similar to Google page ranks). I wasn’t so warmly invited to this second group. Perhaps my pointed posts helped kill the first certification forum.

Never one to be subdued by rejection, my response is to move forward on my own and establish a basis for a certification program for test-driven development (TDD). My intent is to produce a skill-based TDD curriculum, one about as rigorous as a typical university course. Is there a test? Is there a certificate? That’s probably not something I can build as a sole proprietor, but I’m open and ready to work on creating a standards body for TDD certification.

What are my motivations? They of course include profit, but they also include my strong interest in improving the level of professionalism in software development. While some decry profit motivations based on their belief system, certification schemes are primarily about profit, and I believe competition usually drives improvement. Let’s get competing!

Comments:

Actually my nightmares will become a reality when certification in the Agile world comes. It’s close when you end up working for a moron with agile certificate, who knows shit about Agile software development – sorry, I couldn’t resist. It seams, it’s a time to create 4000 pages long agile process guide.

===
Right now, agile is “whatever Joe schmuck wants it to be,” for better or worse. To paraphrase the agile alliance folks, agile certification is coming, and their version of it is really going to suck.

I won’t bother if I think my version of certification is going to suck. If I certify someone, it will mean that I’m pretty confident that I would hire them, at least with respect to their TDD skills. If I can’t find a way to make that

===
I’m relatively new to the Agile world, but already I’m sick and tired of hearing to people who’ve read a book (any book) on Agile methods be a self-described expert.

I’m all for seeing a certification for Agile development. I’m curious to see if it would be biased towards any of the practices, or to general practices.

===
I think agile is interesting in that it doesn’t say all that much. That’s why it’s possible for the Scrum machine to offer a two-day class on Scrum. After talking about iterations, meetings, pigs, and chickens, what’s left? The challenge in agile is not in its mechanics but rather in learning how to solve problems (which are usually people problems) and improve upon such solutions regularly.

So I’ve decided for myself that at least TDD certification is valuable, because it is a demonstrable skill, whereas something like “general problem solving in an iterative context” is not so quantifiable.

===
To the anonymous who is new to the Agile world. Certification won’t make these people to shut up, actually I think they be first who get certified, so they could prove you they are actually an expert. Any discussion will end up with a statement “Don’t tell me I’m certified, so I do know how it should be done”.
Let me tell you an anecdote.
“The juggler was looking for a job and went for an interview to one of th circus. The CEO took a look at his resume and said:
– I see you have a juggler certificate. Can you juggle with 3 balls ?
– Yes, I can – replayed juggler.
– Can you juggle with 5 and more ? – asked CEO.
– Yes, I can – he replayed with a little smile.
– Great, that way I hire you – said CEO.
– But wouldn’t you like to see me juggling ? – asked the juggler.

Yes, I’m amazed at how we hire today. I’ve even had a number of people suggest that making people pair during interviews “just isn’t fair.” What, actually expect that they can demonstrate they know how to do what they’re about to be paid lots of money to do?

Still, we perceive some value in diplomas and university courses. I think there is value in the information that comes from close-knit interaction over several months, enough to say that “this person has potential.” Is a 15-week mentor/protege relationship be a sufficient basis for recommendation?

-j-

Atom