I spent the last two days (in between the usual BS) writing a simple orbital simulator in Clojure using Java interop with Swing. This was a very pleasant experience, and I like the way the code turned out – even the swing code!

You can see the source code here

Those of you who are experienced with Clojure, I’d like your opinion on my use of namespaces and modules and other issues of style.

Those of you who are not experienced with Clojure, should start. You might want to use this application as a tutorial.

And just have fun watching the simulation of the coalescence of an accretion disk around a newly formed star.

How much test coverage should your code have? 80%? 90%? If you’ve been writing tests from the beginning of your project, you probably have a percentage that hovers around 90%, but what about the typical project? The project which was started years ago, and contains hundreds of thousands of lines of code? Or millions of lines of code? What can we expect from it?

One of the things that I know is that in these code bases, one could spend one’s entire working life writing tests without doing anything else. There’s simply that much untested code. It’s better to write tests for the new code that you write and write tests for existing code you have to change, at the time you have to change it. Over time, you get more coverage, but your coverage percentage isn’t a goal. The goal is to make your changes safely. In a large existing code base, you may never get more than 20% coverage over its lifetime.

Changes occur in clusters in applications. There’s some code that you will simply never change and there’s other areas of code which change quite often. The other day it occurred to me that we could use that fact to arrive at a better metric, one that is a bit less disheartening and also gives us a sense of our true progress.

The metric I’m thinking about is percentage of commits on files which are covered by tests relative to the number of commits on files without tests.

In the beginning, you can expect to have a very low percentage, but as you start to get tests in place for changes that you make, your percentage will rise rapidly. If you write tests for all of your changes, it will continue to rise. At a certain point, you may want to track only a window of commits, say, the commits which have happened only in the last year. When you do this, you can end up very close to 100%.

If you think this through, it might seem a bit dodgy on a couple of fronts. The first is that having tests for code within a file does not mean that that code is completely covered by those tests. But, I often find that the hardest part of getting started with unit testing is getting classes isolated enough from their dependencies to be testable in a harness at all. Another dodgy bit is the fact that once you get some tests in place for a file, all of the commits you’ve ever done for that file count in the percentage. Again, that’s okay for fundamentally the same reason. Once you start getting coverage, you are in a good position with that particular code.

What about the moving window? If you track this metric over, say, the last N months of commits, you’ll progressively lose information about the code that you just aren’t changing. To me, that’s fine. Coverage matters for the code that we are changing.

The metric I’m considering (maybe we can call it ‘change coverage’) gives us information about how tests are really impacting our day to day work. Moreover, it’s likely that it would be a good motivational tool, and really, that’s one of the things that a good metric should be.

Surprising revelations while taking a TDD approach to writing hello world.

Here it nearly 21 years since I started writing in C++ (and more for C+) and I realize I’ve been blindly writing main functions to actually do something.

This insanity must stop!

What am I talking about? Read it here.

Can anyone create a simpler version of prime factors in Clojure?

(ns primeFactors)

(defn of
  ([n]
    (of [] n 2))
  ([factors n candidate]
    (cond
      (= n 1) factors
      (= 0 (rem n candidate)) (recur (conj factors candidate) (quot n candidate) candidate)
      (> candidate (Math/sqrt n)) (conj factors n)
      :else (recur factors n (inc candidate))
      )
    )
  )

You have no design sense.

OK, discuss.

@JoshuaKerievsky wrote a blog entitled “Sufficient Design”.

Josh makes this point:

‘Yet some programmers argue that the software design quality of every last piece of code ought to be as high as possible. “Produce clean code or you are not a software craftsman!”’

He goes on to say:

“Yet ultimately the craftsmanship advice fails to consider simple economics: If you take the time to craft code of little or moderate value to users, you’re wasting time and money.”

Now this sounds like heresy, and I can imagine that software craftsmanship supporters (like me) are ready to storm the halls of Industrial Logic and string the blighter up by his toenails!

But hold on there craftsmen, don’t get the pitchforks out yet. Look at the scenario that Josh describes. It’s quite revealing.

Josh’s example of “not being a craftsman” is his niggling worry over a function that returns a string but in one derivative case ought to return a void.

Horrors! Horrors! He left a bit of evolved cruft in the design! Revoke his craftsman license and sick the dogs on him!

Ah, but wait. He also says that he spent a half-day trying to refactor this into a better shape but eventually had to give up.

The fool! The nincompoop! The anti-craftsman! A pox on him and all his ilk!

---

OK, enough hyperbole. It seems to me that Josh was behaving exactly as a craftsman should. He was worrying about exactly the kinds of things a craftsman ought to worry about. He was making the kinds of pragmatic decisions a craftsman ought to make. He was not leaving a huge mess in the system and rushing on to the next feature to implement. Instead he was taking care of his code. The fact that he put so much energy, time, and thought into such a small issue as an inconsistent return type speaks volumes for Josh’s integrity as a software craftsman.

So, as far as Josh Kerievsky is concerned “Sufficient Design” is “Pretty Damned Good Design”.

Look, all our software will have little tiny warts. There’s no such thing as a perfect system. Craftsmen like Josh work hard to keep those warts as small as possible, and to sequester them into parts of the system where they can do the least harm.

So the only aspect of Josh’s post that I disagree with is his contention that the “craftsman” message is one of unrelenting perfection. Craftsmen are first and foremost pragmatists. They seek very high quality code; but they are not so consumed with perfection that they make foolish economic tradeoffs.

As I have said before, there’s nothing particularly wrong with the current mania for certification. If you want to be certified at the cost of a 2-day course, by all means get certified. If you want to certify people for attending your 2-day course, by all means hold the course and hand out the certificates. It’s all good. Make money! Be fruitful and multiply!

But be careful not to waste your time.

How could certification be a waste of time? That depends on your motive.

• If you are getting certified in order to impress someone, like a hiring manager, or a recruiter, or your peers, you are wasting your time. Nobody worth impressing is going to find this certification impressive. Indeed, the people you really want to impress are likely to find it a bit mundane.
• If you are getting certified in order to get hired, you are wasting your time. Nobody is going to hire you simply because of that “C”, and nobody worth working for is going to require that “C”.
• If you have decided to hire only certified people, you are wasting your time. The population of certified people is not richer in talent, skill, or knowledge. Indeed, it may be poorer. Remember, those who have talent don’t need certification as much as those who don’t.

What part of certification is not a waste of time?

• The primary benefit you are getting is the instruction; but be careful: There are lots of pretty mediocre instructors out there. Some of the instructors teach pretty good courses, but others are just hoping that all you care about is the certification.
• So do a little research and find the best instructors. You may, in fact, find that some of the best instructors and courses do not offer certification. That shouldn’t stop you from considering them.

But wait, aren’t the instructors certified as trainers?

• Sure. They paid the money and took the course to become a certified trainer.
• But that doesn’t necessarily mean that they:
  • are a good instructor.
  • know what they are teaching.
  • have done what they are teaching.
  • are qualified to teach you.

OK, but isn’t there some benefit to the certification itself?

• Sure. A nice piece of paper.

Every once in a while in life, you get a lucky break. My lucky break was right as I was graduating from college. One of my favorite professors told the class that there were some people interviewing potential hires on campus and they were looking for a programmer. I remember standing dutifully outside his office, in line, waiting for my little mini-interview. When it was my turn, they didn’t see me for a little while – the door stayed closed after they let the last interviewee out. I found out later, that my professor was telling the interviewers that I was the guy that they wanted.

I came in, and showed them some code I’d written outside of schoolwork, and we talked about it. I told them about my passion for programming languages and they said that the job would be at a research department and they needed someone to design and implement a new programming language. I was over the moon. It was my dream job. And, sure enough, it was real. When I was hired, I sat down with my boss and went over ideas for syntax with him, and he pretty much left me alone for a couple of months to design the language, and implement a compiler for it. I was sitting in my first job, with some real responsibility, struggling with YACC, designing a symbol table. It was all very heady.

In retrospect, I was extremely lucky. I not only had more individual trust and responsibility than many developers ever get in their career, I also became part of an extremely good working environment. The guys who hired me, David Lopez de Quintana, and Carlos Perez, also ran the team I was part of. We were a group of about four which eventually grew to about 12. Although, we weren’t working on one big integrated project, we saw ourselves as a team and we had a great cooperative culture. We each had our area of expertise, and most of us were in our 20s, ready to stretch. We tackled all sorts of interesting problems at the intersection of software, mechanics, electronics, optics, physics, chemistry and biology.

About six months into the job, I had an odd experience. Carlos called me to his office and told me he was going to give me my review. I was a bit shocked. The way I understood things, David was actually the guy I worked for, and Carlos headed up part of the team but not my part. Carlos gave me a big smile and said “Yeah, well, you’ve been working for me for the past few months, but we didn’t tell you.”

The review went great and I happily went back to work. I always knew that, on paper we were two different teams, but Dave and Carlos treated us as one big team. We had one big meeting every week or so, and they shared responsibilities and pretty much kept us from having to care about anything outside the work we had to do.

It was a very cool experience. Sometimes, Dave would spend more time outside the team, sort of managing our interface with the rest of the organization. Part of the group wrote software to support research but we had customers outside of our group too. Dave would be off at meetings, and Carlos would handle the day-to-day stuff with our team. Sometimes they reversed the roles. Dave would handle us day to day and Carlos would manage the world outside. The thing is, no one was asking them to allocate responsibilities that way; they just found it a comfortable way of working. It was pair management. Sort of like pair-programming, but at the management level.

The funny thing is that I haven’t seen this much since. Yes, I’ve visited organizations with teams that do something close to this, but it seems like all sorts of forces are aligned against it. The thing which made it work for Dave and Carlos is that they were very good friends. They were hired at the same time in entry-level non-management positions and they rose through the ranks together. They saw each other outside work all the time and joked together at work, making it all a very rich experience. Importantly, their manager never seemed to put them in competition with each other. As I reflect on it more, I think that was the key. Managers are often in competition with each other and that can impede the sort of collaboration and culture that Dave and Carlos built up. They created a wonderful high-performing team. It was one of those once in a lifetime things, and it’s a time that I’ll always remember.

Whenever I think about team health and culture, that first team I joined is my benchmark. I don’t know where the magic came from, but it was there and I think that the culture that Dave and Carlos created with pair management was a very important part of it. In their interactions with each other, they provided a model for us, showing us how to treat each other at work.

I once heard a story about the early days of the Concorde. A british MP was on board for a demonstration flight. As the jet went supersonic he disappointedly commented to one of the designers that it didn’t feel any different at all. The designer beamed and said: “Yes, that was the tricky bit.”

I wonder if the MP would have been happier if the plane had begun to vibrate and shake and make terrifying noises.

While at #openvolcano10, Gojko Adzic and Steve Freeman told the story of a company in which one team, among many, had gone agile. Over time that team managed to get into a nice rhythm, passing it’s continuous builds, adding lots of business value, working normal hours, and keeping their customers happy. Meanwhile other teams at this company were facing delays, defects, frustrated customers, and lots of overtime.

The managers at this company looked at the agile team, working like a well-oiled machine, and looked at all the other teams toiling in vain at the bilge pump, and came to the conclusion that the project that the agile team was working on was too simple to keep them busy. That the other teams’ projects were far more difficult. It didn’t even occur to them that the agile team had figured out the tricky bit.

As you are probably aware the Scrum Alliance is planning to offer a Certified Scrum Developer program. You can read about it here.

Interestingly enough Microsoft, in collaboration with Ken Schwaber, is offering a Professional Scrum Developer program. You can read about that here (look carefully at the url).

The scrum alliance program seems to be about agile skills. The Microsoft program seems to be about Visual Studio. So all is right with the world.

Is there anything wrong with this? Is this somehow immoral or bad? Not at all. This is just people doing what people do: Selling services and making money. I’m all for it. I expect the courses to be of a quality that you’d expect from professionals; and I’m sure that students will learn useful information. Indeed, from time to time, even I have offered CSM courses taught by people I trust and respect.

There are, however, some claims that need to be dealt with. The most important is that these programs shorten the recruiting process.

I’ve been thinking about offering a Certified Recruiter for Agile Professionals course. This fifty-two week course will teach, and reteach, a number of principles of Agile Software Certification. I call this repertoire of principles: R.E.A.L.I.T.Y.

The first principle is the Redaction of Certification Principle (RCP). The principle states:

Certifications generally certify nothing whatever about experience, knowledge, or skill. Generally they certify that the certificate holder has attended (or at least paid to attend) a course. Perhaps they took (and maybe even passed) an exam based on that course.

Based on this principle, any recruiter taking my Certified Recruiter for Agile Professionals course will not be allowed to complete the course or receive their certification until they have taken the following oath.

As a Cerftified Recruiter for Agile Professionals I solemnly swear before Knuth and all here present:

That before I read a resume, I will find every use of the word “certified” on that document and redact it with whiteout.

That if a candidate uses the word “certified” in an interview, I will ask the candidate to repeat him- or herself without using that word.

That I will pay no attention whatever to any implications of that word, nor will that word in any way influence my opinions regarding that candidate.

This oath is an exemplar of the Certification Nullification Principle (CNP), which is another of the R.E.A.L.I.T.Y. principles of common sense and moderately competent thinking. The principle states:

The word “certified”, when used in the context of Agile Software Development, is a filler word that has no bearing on anything salient or interesting about individuals, skills, knowledge, or anything else. It is a marketing word similar to “new”, “improved”, “natural” and “organic”. It can safely be removed from all documents and discussions without changing their meaning.

This principle leads to the well known Certification Uncertainty Principle (CUP), yet another of the R.E.A.L.I.T.Y. principles. This principle states:

Any acronym that includes the letter ‘C’ standing for the word “Certification” can be safely changed into a similar acronym that eliminates the letter ‘C’ and puts a ’?’ at the end. This transformation of the acronym vastly improves the meaning of the orginal.

That last sentence probably requires some justification. After all, extraordinary claims require extraordinary substantiation. So lets try a few experiments:

Statement                    Ac'nm   CUP  Resulting Statement 
---------------------------- -----   ---- ---------------------
Certified Scrum Master        CSM    SM?  Scrum Master?
Certified Scrum Developer     CSD    SD?  Scrum Developer?
Certified Scrum Trainer       CST    ST?  Scrum Trainer?
Certified Scrum Professional  CSP    SP?  Scrum Professional?
Certified Scrum Product Owner CSPO   SPO? Scrum Product Owner?
Certified Scrum Coach         CSC    SC?  Scrum Coach?       

As we can see, the meanings of the statements are indeed clarified. In my course the Certified Recruiter for Agile Professionals is taught that the question mark is the most significant aspect of each of the resultant statements.

In recent weeks we have uncovered a potentially profound new principle which we may find necessary to include in the R.E.A.L.I.T.Y. repertoire. This is the so-called Scrum Exclusion Principle (SEP) which tentatively states:

Wherever the word SCRUM appears in any statement, or is represented within any acronym, it can be safely excluded without changing any meaning.

The following table show just how profound the effects of this principle are:

Statement                    Ac'nm   CUP  SEP   Resulting Statement 
---------------------------- -----   ---- ----  ---------------------
Certified Scrum Master        CSM    SM?  M?    Master?
Certified Scrum Developer     CSD    SD?  D?    Developer?
Certified Scrum Trainer       CST    ST?  T?    Trainer?
Certified Scrum Professional  CSP    SP?  P?    Professional?
Certified Scrum Product Owner CSPO   SPO? PO?   Product Owner?
Certified Scrum Coach         CSC    SC?  C?    Coach?       

We are not yet willing to say that these transformation are a reliable feature of nature. We can only say that, at this point, there are very troubling implications that support it.

Our final advice to Certified Recruiters for Agile Professionals is based on one final principle: The Smoke and Mirrors principle, (SAM) which states:

Well… You know what it states.