In a blog interview Rick Hightower admits that he finds that ant is still ahead of market share with maven. Still he feels that Maven uses a better concept, but the implementation isn’t that great.

My experiences with Maven have been pretty negative. I’ve tried it twice in the past, because I like the concept as well. Both times before I got very far I ran into nasty exceptions and I couldn’t get any further. Despite some expressed interest none of the developers at my company have spent enough time to figure it out and try to sell the rest of us on it.

At the end of the day I only have so much time to keep up with new tools, and Ant works fine despite it’s verbosity. (Maybe Maven 2 will be really good and make me reconsider.)

Being a bit of a book nut, in an average month I devour about 3 software development titles. I do a great deal of my learning via the printed page. So I’ve never questioned the value of buying books for developers even encouraging them to order books on any development topic they’re interested in.

I remember quite a few years I had a compatriot who was given a $2000/year to spend on training and that one of his options. I remember being just a bit jealous. Anyway I vowed whenever I got the chance that I would implement a book budget for my employees. The benefits are just too obvious:

• Say an average developer orders about 1 book a month on Amazon for an average of $30. For one developer that costs you about $360 per year. Typically cheaper than a single day of vendor training or one day at a conference.
• Most of the reading will take place outside of working hours, and typically if a developer is doing some reading at work or going through examples it’s during downtime anyway.
• A book budget is a nice perk for a lot of developers and can help convince them that you really believe in investing in them.

As a last point if you’re a manager you should assume when you buy a book for someone that it’s pretty much theirs. Occasionally employees share books or pass them around, but typically they like to keep them around as personal references. If you need to buy two copies or more of something, just go ahead and do it. I’ve never seen a library type system work where the company owns the books and you have to explicitly check them out. Basically it’s just an extra layer of hassle for developers. Besides that the library space typically becomes a dumping ground for dated technical manuals and people stop even bothering to check it out.

Ship It! A Practical Guide to Successful Software Projects is a really quick read. I’m 100 pages deep now and I’ve got two sides of a 3×5 card filled with new ideas including things like lots of constant buddy/mini code reviews instead of pair programming.

I’m sure I’ll end up experimenting with a bunch of the ideas, and I’m a little surprised at how much I’m enjoying the read. I picked it up thinking it might have some good ideas, but that I probably knew much of the content. I recognize a lot of the ideas, but they’re able to present them in novel ways and cite clever anecdotes that keep my mind really engaged. This is the sort of book that impresses me with the Pragmatic Programmers series.

Of course I did notice one practice they suggest is keeping ‘The List’ of all the project features. The idea is really similar to Scrum’s backlog, but they were inspired by Stephen Covey’s writings on the ‘7 Habits’. Personally I’m more of a ‘Getting Things Done‘ (GTD) fan, and David Allen the unlikely guru suggests that the idea of a daily list really doesn’t work for most people.

I’d have to agree I find I almost always put stuff on a daily list and then fail to get most of it done. All it means is I have to copy it over to the next day and feel guilty about it, not exactly a successful system. With GTD I just stick the item into a context like @Computer and only items that absolutely have to get done on that day get done like ‘Turn in final employee reviews to HR’. I find it to be a much cleaner system. Feels like a more pragmatic approach to me.

Given the amount written about unit testing in general one would think that many organizations had adopted it by now. If XP has done nothing else it had apparently been able to make testing cool with developers. That alone is quite an accomplishment. Some of the signs of its’ widespread popularity include:

• After only a few years there are xUnit frameworks for almost every language from .NET to PHP

• There are many popular open source testing tools beyond xUnit including:

• CruiseControl, AntHill
• HttpUnit, JWebUnit
• Mock testing frameworks EasyMock, JMock
• StrutsTestCase
• Replacements for JUnit like TestNG
• DbUnit

• And many others …

• Support for running JUnit is built into every major Java IDE.
• A whole host of books have been written specifically on unit testing.
• A greater number of books and articles touch on unit testing such as all the XP books.
• Many of the Agile methodologies assume unit testing and automated builds as basic supporting practices. After reviewing a number of resumes, conducting quite a few phone interviews, and a few in person interviews for an opening for a senior J2EE developer I’m starting to seriously reconsider my assumptions. The reality is almost all the resumes I see mention experience with at least JUnit in the list of skills and experience. Then you start asking questions of candidates.

As it turns out over the last 3 months of conducting interviews it’s turned out in every case that the candidates had little real experience writing unit tests. Most of them had apparently used JUnit at least once, but generally didn’t use it on their projects and often the only unit tests they had ever written were written against DAOs which invoked a live database.

Often they’d explain that they used JUnit and unit testing for a project or two, but early on the developers had stopped writing the tests and they were rarely if ever run after being initially written. One explained that they did write a fair amount of unit tests, but they never used JUnit and had instead written their tests into main methods in all their classes that could then be executed individually. In the past three months this is the best I’ve seen as far as good practices go.

I realize that my current experience is a tiny sampling of the IT world out there, but it leads me to believe that a majority of the J2EE development world really hasn’t instituted any significant unit testing practices into their development methodology.

I can see evidence of this even within my own organization. My senior developers run CruiseControl, write a significant number of unit tests, and are constantly researching new testing techniques like Fitnesse or JWebUnit. When I came onboard over a year ago now I was impressed with their level of sophistication in these practices. As things have evolved I’ve of course seen much of the reality.

• We have over 700+ unit tests for our major enterprise application, but it is far to few to truly test the system.
• The majority of the tests are actually functional tests that invoke a lot of database transactions and rules from a commercial rules engine.
• The full test suite runs for over 25 minutes so it’s only run by CruiseControl.
• The majority of the time our build is broken and some unit tests are failing, but fixing current defects from QA almost always outweigh getting the unit tests passing.
• Developers admit that despite believing in unit testing, if they feel any sense of time crunch they opt to stop writing tests first.

So I hope my experience has just been a statistical anomaly, but I fear it’s pretty close to reality. I do know that I personally feel like I’m diving off the deep end into an empty pool if I’m not writing tests. I don’t plan to go back to the days of just hoping everything worked with no tests in place. And I do love green bars and quick feedback. Now I just need to harness some of that passion to bring our development organization along. (And I need to remember not to be so dogmatic, that’s always dangerous)

I just came across the ObjectMother pattern for creating a factory object to provide all sorts of test objects for unit testing. Essentially you create a class or classes with lots of nice static methods that return already setup objects for testing. This is especially helpful on larger projects where you have a lot of code that gets into each

method. I’ll probably try it out on some of my home projects before I try to sell anyone on my team with using it.

Interestingly enough most of the blog entries that come up high when you google for ‘ObjectMother’ are for .NET developer blogs. I don’t know if that says anything about the pattern or not.