Thinking Inside a Bigger Box

People always talk about how learning is something that happens in groups. Last week, I got reminded of the point as a task I had previously struggled with alone became trivial in a pair programming episode.

The first time I tried coding “a bowling scoring program” was in 2001. I’ve practices the exercise many times later. In 2004, I tried to write a more challenging version: Write a program that prints the numbers that should be displayed on a score board for a partially played game of bowling. I got bogged down and sidetracked, and didn’t come up with a very good solution at all.

Last week, my company invited Ron Jeffries and Chet Hendrickson to give a short course in pair programming and test-driven development for 15 of our developers/testers. Ron and Chet has coded this particular program a number of times, but never with the score board variation I mentioned.

In the second half of the course, I sat down with two others of our developers who had never worked on this exercise before. We quickly finished the simple game, and then someone proposed the score board. I said “oh, that’s way too hard, we’ll never finish it in time for the course”.

To make a long story short: I was wrong. Together, we solved the problem in no time flat.

Many people enjoy splitting testing up in a myriad of test types: Acceptance Tests, Functional Tests, Integration Tests, Performance Test, Technical Tests, Unit Tests. I have myself been guilty of such terminology as “embedded integration tests” and “requirement tests”. However, what unites the tests are more important than what divides them. The divisions are fuzzy, and they should be.

All tests have but two purposes: To tell you if you’ve completed a new requirement, and to ensure that you haven’t broken something that worked. There are three fundamental properties of a good test suite: Coverage, Robustness and Speed.

Read the rest of this entry »

Myopia: the inability to see distant objects as clearly as near objects. PreferredConsumer.com

What makes a good statement? In my experience, a good statement is one that people will disagree with frequently. One of the internal quality auditors at my company has an excellent plaque in her office: “If you and I agreed all the time, one of us would be superfluous”. So, in the spirit of disharmony: Agile development is all about being myopic, that is, short-sighted.

One of the things that has always impressed me with people preaching waterfall, RUP, or traditional CMMI is how skilled they are at looking into the future. For me, this has never worked out well. I keep writing down requirements for projects that never happen, design my systems for requirements that turn out to be canned in the end, and coding my designings in a generic way, just to find out that the generic way I have designed the system, is different from the genericity that I really needed. *sigh*. I need a better crystal ball.

Read the rest of this entry »

Recently, there has been a discussion about code comments on the pragmatic programmer mailing list: “Should you comment or not? What should be commented?”

The one point I haven’t seen expressed succinctly is the following: Given a finite amount of time and a codebase with some … issues (which codebase doesn’t have issues?) what is the most useful thing you could do with your time? How often is the answer “comment more”?

Many factors determine the answer: If the code has good test coverage, you can refactor it with impunity. That might be a better way to spend you time. If you’re good at “blind refactoring”, maybe you could restructure the code to bring more under test? Maybe you could improve the test coverage? Given finite amount of time, it is a question of priority.

A is for Apple You may have already known that A is for Apple. But did you know that O is for O’Reilly? Check out what Google reports for single character queries. (From Ward Cunningham’s Weblog)

This book talks about the role of a tester in an XP project. So it is about acceptance testing, not unit testing (see Test-Driven Development by Kent Beck for that).

The long and short of it is that I would really like to run an XP project with people who have read, understand, and become excited about this book. My experience is that a project suffers from not having someone who’s job is 100% quality. Programmers (myself included) will sadly have too much at stake to be effective at testing their own code. Having someone who is dedicated to acceptance testing on the team will also be a good way of keeping the iteration cycle short while delivering software of good quality.

I did notice a few weird things about the book, though. The choice of webART as an example of a web acceptance testing tool seemed to me to be a bad one. My impression from the book is that webART is a rather verbose language. The book also suggest estimating down to hours (and in some cases, below that). Personally, I don’t have enough predicability in my progress to do this, but I guess your milage may vary.

All in all, a very good book. I hope to get a tester who works with the mindset the book describes on my next project.

Test-Driven Development describes in detail this technique from Extreme Programming. In addition, the author spends some time teaching the reader a useful set of mental tools for writing better code. TDD is a very fast read, but it is full of useful information. If I wanted my developers to only read one small book about software development, this would be it.

Note: The back of the book lists it as “Software Engineering/Testing”. This is incorrect. Test-Driven Development is not about testing, it is about programming.

Highly recommended.

This is exactly the kind of thing I have been looking for in C#. I am still some ways away from having looked at it as thorough as I would like, but it looks very good.

Basically: Attributes that are processed compile-time with any code you like. This is the basic building blocks for AOP.