I've lost count of the number of times I've heard that. I've even said it myself a few times.

It seemed like it would be pretty easy to do using the dashboard.xml feature of AgitarOne, so I decided to give it a try.

What a great end to the first year of JUnit Factory!

Let them eat cake!

at an international gathering, the French-speaking people will have no idea what you are talking about. Even if you say it in French.

In my younger days, before I knew any better, many projects I worked on compiled and published their software manually. You'd type cc and then copy these bits over there and then zip that directory and post it to there. Eventually, we figured out we could write little scripts to automate all the tedious bits and make it less fragile and more repeatable.

One day, I discovered the discipline of daily builds and tools like make and my life got a whole lot better. Make gave us, in Elizabeth's handy phrase "a place to put things".

In Influence: The Psychology of Persuasion, Robert Cialdini describes various techniques for making people do things that, if they were thinking clearly, they would otherwise not do because of lethargy, laziness, or because it would offend their better judgment.

One of those techniques is The Commitment Principle which was used on American POWs to great effect by the Chinese during the Korean War.

Here are a few that I use all the time:

• xml, xpath & xslt
• JSP, EL, JSTL
• Regex

Any more I should know about?

2.1.3 A strike is made when a full setup of pins is knocked down with the first delivery in a frame.

Before I move on to the next story, I want to revisit those tests and make sure we have not introduced any regressions.

If I am not mistaken, I have written enough code to pass the acceptance tests for this story.

find out whether something works correctly

The topic comes up about once a year on the TDD mailing list and it just came up again. By an odd coincidence, we just celebrated the completion of a new release of AgitarOne with a trip to Homestead Lanes, so I am all fired up about bowling despite my dismal performance (there was beer involved).

The main lesson: no one reads anything.

Those in the Agile world all know of resistance to Agile from those middle managers who see it as a threat to their power to command and control. Telling such a person that her sabotage endangers the company's ROI is like an abbot standing in the path of Christian raiders and threatening them with loss of their immortal souls: sometimes it works, but nowhere near often enough. And it never works with the worshippers of Odin.

Executive Summary

If the build fails, fix it.

But what to do with that failing test?

But what to do with that failing test?

Is there such a thing as too much feedback?

XP doctrine says that you should stop tracking metrics once they have served their purpose. You should only have 3 or four "Things To Focus On". There's a reason for that.

1. Test your own code as well as you can
2. Next time someone checks in a slap-your-forehead bug, show them the test that would have caught the bug if only they had run the tests.
3. Show them how to run the tests themselves

It won't be long until everyone will want to have tests.

Most developers will not make the investment until they have seen proven returns. The management challenge is to find the early adopter with the courage and vision to take that first step.

BTW I often use the Adapter Pattern to wrap a class that seems to need utils until eventually the Adapter grows into a whole new class of its own. I have done this to add utility functions for parsing and xpath querying to org.w3c.Document for example.

I ran a coverage tool on a project of mine last night and found that almost all the coverage gaps were in boilerplate code. An interface required me to return false in a whole bunch of classes.

The duplication was already bothering me. The duplication plus coverage gaps bothered me enough to extract a common base class. Coverage was back up to almost 100% and I liked the new design better.

Go figure.

I want you to build a Hello World application in J2EE. I want you to do the simplest thing that can possibly work.

I have worked with many testing common organizations where a common pattern is repeated over and over. It goes something like this — we realize there is more manual testing to do than time available, we decide to automate the testing, and we begin working on a test harness. Several weeks later, we have the start of a harness, but it’s barely useful and we still have not written any tests. At this point, we’re behind — so we abandon the harness and revert to manual testing.

Full article [PDF]

Applications that pop themselves to the front.

(are you listening, IntelliJ ?)