Testability & Good Design

Much of the time, the test-driven development yahoogroup is pretty quiet, but it has recently awakened from winter hibernation.  The question “Is it OK to add code to a class only to improve its testability?” stirred up a wide-ranging discussion that brought in the topic of what constitutes good design.  “Uncle Bob” Martin drew a bold line in the sand with his comment,

One reasonable definition of good design is testability.  It is hard to imagine a software system that is both testable and poorly designed.  It is also hard to imagine a software system that is well designed but also untestable.

I greatly sympathize with this statement, though I wouldn’t go quite that far.  I don’t think it is so hard to imagine code that is testable, but poorly designed.  For a trivial counter-case, there could be rampant duplication of testable code.  I would call that poorly designed, but it doesn’t affect it’s testability.  Therefore I would soften Uncle Bob’s definition to “One reasonable component of the definition of good design is testability.”

To me, the notion of “testable code” is the same thing that “testable circuit” was back when I worked on a custom integrated circuit.  Mostly, that depends on the ability to put the circuit or code into a known state, exercise it, and see the interactions with its collaborators and its resulting state. Read More

Agile Retroflection of the Day

Yves Hanoulle asks, “If you could change 1 thing today what would it be?” as the first question in his Agile Retroflection of the Day project. Today being the first of the year, it’s natural that I look back over the past year as I consider this question.  And so I answer,

That people could ask for, and could accept, the help they need and want. Read More

Tracking your investments

The world is slowly recovering from a major financial meltdown.  People blame the collapse on a number of different things: a bubble of inflated housing prices, relaxed requirements for qualifying for a mortgage, predatory lending practices, greed on the part of mortgage companies and investment banks”¦.  There are certainly many places to point fingers.  Each of these places, however, was doing what seemed logical when looking at a small piece of the puzzle.

As is often the case, we must back up and take a larger systemic view to see further.  Once upon a time, people borrowed money to buy a house, paid it back over time, and ultimately the bank was able to lend that money to someone else.  With the creation of the FNMA (Fannie Mae) in 1938, the income streams of those mortgages being repaid were converted to bonds, so that they could be sold to other investors and the banks to re-lend their money more frequently.  This allowed many more people to afford houses.  In the 1970s, private banks got into the business of creating their own bonds based on debt repayment streams.

Nothing ever stands still, of course.  People continued to look for new wrinkles on these themes to allow them to expand the business, or to increase the profit on the business they had.  Some of these investment vehicles got very complicated, intended only for professional bankers who could understand and evaluate them where the mass public could not.  Or, so went the pitch at the time. Read More

I do not endorse PMAC Certification

It has come to my attention that the PMAC (Project Management Association of Canada / Association de Management de Projet du Canada) claims that I support their certification program.  This is a lie.  I do not support their certification program.

Their claim seems to based on a mailing list posting in which I said,

I applaud your efforts to educate the “traditional project manager” in Agile techniques.  I hope that you are very effective in doing so.

  • I did not say anything about their certification program.
  • They did not ask me if they could use my words on their web site.
  • They have fraudulently quoted me as if I have endorsed their certification.

I am all for education. I am suspicious of certifications. I am angry that I have been so misrepresented.

I consider this misrepresentation to be a sleazy trick. It give me the impression that PMAC is not to be trusted. I suggest that you be wary of them.

It’s not the script, it’s how you do it.

I’ve had numerous discussions with Michael Bolton where he makes the claim that scripted testing (whether via automation or a person following written directions) is not testing but checking.  He quotes Cem Kaner‘s definition of testing: “testing is an empirical, technical investigation of a product, done on behalf of stakeholders, with the intention of revealing quality-related information of the kind that they seek.”  Running a script that validates certain desired behavior certainly fits this definition. Read More

4 Comments

Categories: Working Software

Tags:

Proficiency and Fluency in Self-Organization

Ever since I experienced the “Where Are Your Keys” language fluency game with Willem Larsen, I’ve been thinking about how to apply the concepts to learning other than languages.  One of the fascinating concepts I gleaned from this game is the separate dimensions of proficiency and fluency.  The proficiency scale that Willem uses is based on the ACTFL guidelines of Novice, Intermediate, Advanced, & Superior.  Willem gave a memorable colloquial description of these guidelines in relation to a party: Read More

Using User Stories

Since learning about them some nine years ago, I’ve found User Stories to be much handier for expressing what the system should do than the monolithic requirements documents I dealt with in the past.  User Stories have a number of advantages:

  • They can easily be shuffled into a different order.
  • You generally know (by the acceptance criteria) whether or not they’re done.
  • They don’t contain a lot of duplicated or contradictory detail.
  • The detail gets elaborated when it’s needed (rather than a long time prior, letting the details get out-of-date and/or forgotten).

I’ve created a two-page handout on writing and splitting User Stories.  I’m publishing it here in case it helps others.  And I would welcome any feedback on it.

Long term focus

My good friend, Steven M Smith, tweeted

AGILE methods emphasize realizing short-term OBJECTIVES rather than creating long-term objectives and trying to satisfy them.

I completely disagree with this statement.  I don’t agree that short terms objectives are the emphasis in Agile methods and I don’t agree that short term objectives are preferred over long-term objectives.  I think that Steve’s misunderstanding is rooted in the fact that he has only read about Agile methods, and not practiced them.  I think that it is impossible to get a deep understanding of Agile methods by reading without experiencing.  Therefore, I’d like to encourage Steve and others talking about Agile methods to try to get some experience before making such statements.  I’d also like to offer an explanation that attempts to clear up this particular misunderstanding. Read More

Looking back at Agile 2009

Another conference has come and gone.  I’m home.  I’m exhausted.  I’m glad to have good internet connectivity again, and time to sit alone with my thoughts.

I had a fabulous time.  Through conferences such as this one, I now have dozens of friends from around the world that I rarely get to see.  I really enjoy getting together face to face.  Missa vitussa se poro on. (I hope I’ve spelled that correctly.)  And I spent time with friends that I previously only knew from Twitter and email.  And I met new friends that I’d not known before.  All of that was thrilling.  (I also didn’t get a chance to talk with some friends whom I know attended. Life is like that.)

I attended some great sessions.  Read More

58 Comments

Categories: Uncategorized

Tags: