- Consulting / Coaching
- Jeff’s Blog
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.
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.
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.
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!
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 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.
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.
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?