Netuality

A mini-review

The book already has stellar ratings on Amazon, JavaRanch and other select places, and after reading a few chapters, the only thing I can do is add this post on the praise list.

Why only a few chapters ? Well, you see, this is not exactly the type of book that you read from cover to cover, it's in fact a 720-pages solid collection of JUnit best practices, the most comprehensive you'll ever found in organized, written form. Until now, I have found precise answers to all my JUnit questions.

The book is organized in three big sections weighting some 200-250 pages each. The first one ('The building blocks') is hugely useful if you are a JUnit newbie or even an absolute beginner. It's a detailed introduction to everything you'll need to know in order to start using JUnit: basics, usage in mainstream IDEs, testing patterns, managing test suites, test data and troobleshooting advice. Even seasoned programmers will find useful pieces of advice. I especially liked the 5th chapter ('Working with test data') : an exhaustive description of all the possible ways of organizing your test data. To be honest, it's one of the few chapters from the first section, that I've really read.

The second part ('Testing J2EE') covers testing of XML, JDBC, EJB, web components (JSP, servlets, Velocity templates, out-of-container testing & such) and J2EE applications (security and again some webapp testing – pageflow, broken links, Struts navigation). I can't really pronounce upon this section since I've read only a few subchapters (DBUnit and some related JDBC testing, as well as a few pages from the web testing chapter). But every piece of advice I've got was rock solid.

I've read in its entirety the third part ('More JUnit techniques'). Under this bland title you'll find a group of not-so-common JUnit info such as usage of GSBase addon (funny that I wasn't aware that such a useful addon exists). There's also an intriguing 'Odds and ends' chapter containing some interesting recipes (here's a good one for the QA-freaks like me : 'verify that your test classes adhere to basic syntax rules of JUnit' – sure, why not ?).

Something that I've really missed is a chapter dedicated to mock objects recipes. Yes, there is a quick explanation in the first section – and a reference to Easy Mock or some other mocking API pops now and then in different chapters – there's even an essay about mocking at the end of the book. But the main mock objects dish isn't there. I would've also loved to see some automated GUI-testing recipes (Abbot, Marathon & related tools). But then again, it's a >700-pages book so I'm probably asking too much.

To conclude, 'JUnit Recipes' is the best JUnit book I've ever came into contact with and it supercedes on my list 'JUnit in Action'. Which, interesting enough, was published by the same Manning almost a year ago. Can't have too many good JUnit books, don't they ?

… then a software team is like an aquarium.

“Programming is Gardening, not Engineering” says Andy Hunt (of Pragmatic Programmer fame) in one of his well-known Artima conversations.

Inspired by such an interesting ‘organical’ comparison, it’s my metaphor of a software team which behaves quite like an aquarium. I assume not all my blog readers are aquaria hobbists, so let me explain:

• Permanent monitoring and adjusting. Left alone and unsupervised, an aquarium apparently manages to ‘survive’ by itself. However, subtle changes in water chemistry will slowly start to build up. Interesting fact is that fishes seem to cope well with these changes – until a certain balance is reached and they get sick and eventually die. In my experience, the threshold is rather thin, one day everything seems ok and the next day it’s a major disaster. The effort necessary to clean up the situation is significantly bigger than the effort spared by not taking care of the aquarium. The parallel here is quite obvious : you can’t manage what you can’t measure, you can’t control what you can’t manage. Software metrics, code reviews, frequent releases, testing and feedback, these practices are vital if you want a ‘healthy’ project and a ‘living’ team. Otherwise, beware, the inflexion point might be just a few days away*.
• However, changes must be done gradually. Supposing that a major shift in water parameters was detected, taking immediate and radical measures will generally worsen the situation (unless the catastrophy is already there). It is highly recommended to distribute the change over a reasonable period of time and generally never try to influence two major water parameters at the same time (Ph and Gh for instance). Explanation: all these parameters are interconnected in intricate ways, by changing one you’ll automatically influence the others. By changing two or more, the outcome is hard to predict and might open the path to a disaster. There’s a nice parallel here. A major change in methodology with sudden introduction of multiple new/modified development practices, will only make the team unstable. Even if, globally speaking, the change is a highly beneficial one. ‘Good things come to those who wait’ … and measure … and change … and wait … and measure … and change …
• A beautiful aquarium is a visible one. Transparent glass, lights and everything. You wouldn’t feed and keep your fishes if they were living in a black box and you are afraid to look inside it ?

*Of course [and fortunately], the developers do not get sick because of a reeking team/project, they simply leave.

Tomorrow is my last day here as a Senior … whatever. I've done a lot of Java development (Eclipse plugins, SWT/JFace, various components for our proprietary framework) and even some DB work (Sap/Oracle/PostgreSQL migration, benchmarking, testing), spiced with a little bit of API design and a healthy dose of documentation writing. It was a great year with lots of stuff to learn, but it's time to move on towards greater challenges. I'm going back to the web business (this time not under the risky startup umbrella, but with an established company) and back to a managerial position ! Working a full year 100% on a development contract has surely taught me a thing or two about how effective management must be done. I really needed such an experience, because as a young professional (back in 1998) I became very quickly (maybe too quickly) a project manager.

The funny stuff is that I'm going to manage a C# team which is bigger than the Java team. I'm familiar with .Net notions and burning some midnight oil with VisualStudio Express, but there is a serious culture shock of coming from Java/Eclipse development environment. Although C# as a language is very neat and there are some cool MSFT APIs down there, I have the strange sensation of things being terribly awkward. Hope I won't be swallowed by the Dark Side [ugly grin].

If there's any 'actual future former' coworker reading this blog : THANK YOU ! and keep up the good work.

As expected, more RCP-based commercial applications are seeing the light of day. XtremeJ has recently released (28th Sept) the XtremeJ Management Suite v3.0, a set of Java management tools for the developers and administrators to access, manage, and monitor the based services. This suite includes not one, but two Eclipse RCP-based tools, XtremeJ Operations Console and XtremeJ Java Management Tooling. Their site has a lot of eye-candy screenshots … go take a look.

Well, this is the very condensed version of Martin Fowler's latest approach to requirement creep. His idea is : (1) 'start by charging the double thus allowing a comfortable buffer for the project' then (2) 'accept all new requirements without charge, in the limits of the buffer', (3) 'explain and agree with the customer that fixed scope approach was a mirage' and (4) live happily ever after.

At first, the approach seemed fine and I especially liked the 'risk mitigation', which is basically: if at step 3 you enter into a conflictual state with the customer and start rejecting/charging features, then at least you had peace of mind during step 2. Without this little stratagem, you'd be anyway into a conflictual state with the customer from the very beginning of the fixed-price project.

What I have some problem accepting is: point 1, charging the double of the usual rate. In his essay, Martin calmly explains since we have better and more productive people, we can actually do the job for less. So, in order to be able to apply this 'recipy', you have to be at least twice more productive than your competition. This basically places you in the upper region of the Gaussian bell, probably somewhere in the top 10% companies. Well, that's a nice audience ! It's always pleasant to know that you have 90% chances of not being able to apply this advice.

The 'double bill' strategy raises another interesting problem. How would you apply this when the customer is internal ? It is known that internal projects are plagued with massive feature creep (and this is probably one of the main reasons why these projects fail so often). By 'charging' your corporate sponsor (generally, upper management) you're either : asking to double the project length or doubling your team size. Both cases, you're in big trouble.

I guess I'll stick to the old way of doing things: providing good visibility on the project status, estimating each new feature request and letting the corporate pitbulls to do the negotiation dance. That is, until I reach that 10% Nirvana where we are allowed to charge the double.