« July 2004 | Main | September 2004 »

August 26, 2004

It's the little things...

I've been bitching to my team lead lately.

A lot.

About Checkstyle.

Specifically, about our project's insistence on the checkstyle rule that insists imports are optimized. In other words, no imports of unused classes should be used.

The problems I have with this rule are thus:

  1. To my knowledge, there is no downside from having unused imports in your classes from a performance perspective

  2. The entire development team has IntelliJ configured to collapse the import block, so any seemingly horrendous unused imports are invisible to all and sundry unless the block is intentionally expanded again.

  3. Temporarily commenting code (for testing, investigation, etc.) requires re-optimizing imports and an even more painful re-importing process after the comments are removed. This is one of the things that Eclipse seems to do far better than IntelliJ, IMHO.

  4. It's all to easy to dash off to the loo/a meeting after having commenced a run of the test suite, only to return to find the suite only ran for 20 seconds because of unused imports being picked up by Checkstyle (this can be a huge source of time suckage and a vertiable PITA to boot).

  5. Murphy's law insists that the "tiny little refactoring to this class which couldn't possible change the state of the system so I'll just commit it to CVS from within IntelliJ without going to the command line" is bound the break the build (again, after about 20 seconds) because of some unused import that snuck into a class somewhere.

Nevertheless, my team lead has proven quite the immovable object in light of my complaints and I haven't been able to form a lynching mob within the development team to overthrow the evil despot, so I've had to suck it up in this respect.

And then someone informed me that the answer was staring me in the face...

Apparently, for quite some time now, the IntelliJ CVS commit dialog has provided the facility to automatically optimize imports on a commit (see diagram), which completely removes the chances of issue #5 (the biggest time/money waster) ever occurring.


Upon discovering this fabulous "new" features I also found something that does seem to have been added to IntelliJ somewhere between 4.0.3 and 4.5 - a commit tag option. This feature allows the set of files changed during the commit to have their own unique tag. I've never really needed something like this previously, but our project seems to suffer from frequent needs to port sets of changes (i.e., stories and bug fixes) from one CVS branch to another. With this in mind, pre-emptively tagging each commit group with an identifying tag should greatly reduce the pain this porting overhead usually incurs.

So congrats to the Idea team for these couple of little features which have made my life a whole lot easier of late.

Posted by Andy Marks at 01:52 PM | Comments (2)

August 24, 2004

Waltzing with Bears: Part Deux

Having just finished reading Waltzing with Bears, I can heartily recommend it to everyone working in IT project teams. Although the book is primarily targeted at project managers, there is much to be gained from it's content by your common-or-garden-variety developer.

The main blurb on the back cover paraphrases the key point from the first chapter: "if there's no risk on your next project, don't do it". This phrase has an interesting double entendre-ish nature to it: the main point Demarco and Lister are trying to bring across is that projects devoid of risk are likely to be equally bereft of any real business value. As the authors put it - they (the projects) are losers! This is to emphasize the point that people should have a positive attitude towards managing the risks that exist on all worthwhile projects.

But the flipside to this phrase is the false positive project that is seemingly devoid of risk because risk management is not being done at all. And this is where the contents of this book are particularly useful to developers...

A few quick questions for all the fellow developers reading this post:

I suspect most developers out there are like me and cannot honestly say they have firm answers to any of those questions. In an ideal world project managers would take the responsibility of not implementing proper risk management procedures, thereby shielding us from the punitive consequences of their oversight. However, when you wake up and smell the Jolt, we all realise that the buck generally stops with us when unmanaged risks materialize in the face of our PMs. And the sound of that buck stopping is usually accompanied by long hours and short weekends as your project crosses into Death March County.

So, to mitigate the risk of your PM doing nothing to mitigate risks, take a butchers' at this succinct but densely-packed book and arm yourself with a swag of questions to annoy your PM with during your water-cooler conversation.

Posted by Andy Marks at 07:36 PM | Comments (0)

August 18, 2004

Waltzing With Bears

This text on risk management by Demarco and Lister has certainly opened my eyes about the key concepts behind risk management on IT projects. I don't really want to do a full review as I'm not well versed in other contemporary works on the same topic, but I will say it's a very accessible book that presents a compelling argument (through both the recount of real-life project examples and theory) for taking risk management very seriously when managing IT projects.

If (as a developer) you take nothing else from the book, pay very special attention to the sections on "N-Based scheduling" and how just using estimates to set expectations surrounding project completion is almost guaranteed to result in disappointment (i.e., failure to meet the deadlines).

However, the key point I wanted to make was that I've been struck by how well-suited some aspects of Agile/XP development are to the risk management strategies presented within. One of the key concepts they mention early in the book is that of the "transition indicator". A transition indicator is a notification that a risk (i.e., something that will have a negative impact on the cost/schedule of the project if it occurs) has materialized and is in need of attention.

Successful risk management involves identification of appropriately visible transition indicators for each risk and keeping an eye out for their appearance throughout the course of a project. Two recurring risks on any non-trivial IT project are the introduction of new/unfamiliar technology and the omnipresent fear of estimates overruns. Agile/XP provides transition indicators for both of these risks:


XP demands a short technical feasibility study (a "spike") is conducted for any piece of work where a solution is not immediately obvious. The failure to successfully complete a spike for a new persistence framework (for example) is a transition indicator that the identified risk of "new persistence framework may not be suitable" is becoming a reality. Time to mitigate or contain that beastie!


Short iterations are eminently suitable as transition indicators for estimate overruns. Given early overruns are - contrary to the eternally optimistic outlook of the typical developer - unlikely to be recouped in the future, the failure to complete early iterations is an indicator that risks along the lines of "developer estimates may be hopelessly optimistic" are materializing.

Pair Programming and Testing

Although not a transition indicator, the successful use of pair programming and/or rigourous automated testing are both excellent mitigation strategies for another classic IT project risk, that of key personnel leaving the project prior to completion.

Posted by Andy Marks at 10:00 AM | Comments (1)

August 16, 2004

IDE Wish List

With a previous client, I was a fervent Eclipse user/booster. Now, I'm at a client where IntelliJ is king. With a reasonable level of comfort with the two big hitting IDEs for Agile Java developers, here is the first of what could blossom into a long list of suggestions for new features for these tools...

  1. Some form of modeless notification for when a breakpoint is reached.

    Such a beastie would certainly save me a little time when I'm swearing at my browser waiting for it to render and the bottleneck is really back in the J2EE container I'm running in debug mode in my IDE which is sitting patiently at a line breakpoint waiting for me to intervene.

    This notification could be something annoying like a beep, but preferably a status bar popup (similar to those used by Yahoo Messenger) with the message "IntelliJ has halted on a breakpoint" would be sufficient.

Posted by Andy Marks at 04:47 PM | Comments (1)

August 14, 2004

To Sir - With Agility

I spent a considerable amount of time masquerading as a university lecturer/tutor before I started masquerading as a consultant, and I loved and dearly miss my time in the classroom. Perhaps it's not surprising then that I frequently relate my current career to my previous one. Recently, I've begun to realize how successfully Agile practices like those embodied in Extreme Programming could be employed in teaching software development to university students...

Some of the biggest problems I found in teaching in an undergraduate computing degree were:

Wih little effort, I can see existing XP practices tailorable to address each of these issues.

Customer Acceptance Tests
In a classroom, the teacher is the customer-proxy. Therefore, it's expected in an XP world that the customer specify the acceptance criteria for the work they're requesting. If students had a complete set of automated acceptance tests for their assignment work, it would certainly curtail the endless series of "I think I'm finished, but I'm not sure..." statements I was peppered with towards the end of each assignment. The immediate feedback this mechanism provides would greatly reduce the need for the inspection of the teacher to ensure completeness.

Pair Programming
Given most student's learn best with their peers, pair programming should be encouraged at all times during their study.

  • Ensure tutorial sizes are roughly 2n where n is the number of workstations in the lab.

  • Enforce pair changes frequently in the semester to open students to a wide variety of programming styles, and prevent "remora" behaviour where astute but unmotivated students attach themselves to the high-performing developers for the duration of the subject.

  • Continue to conduct individual interviews to assess each student's amount of individual learning.

Given students don't have a natural feel for good program design, let them churn out the simplest thing that could possibly work on their first attempt and then allocate assessment criteria for some form of refactoring. Where possible, use automated metric reporting to give them immediate feedback that their changes are increasing/decreasing code quality, but also use some form of subjective tutor-based assessment to enforce the fact that not all quality can be codified by tools.

Automated unit tests
Let students generate and use an automated unit test suite in place of a written test plan. Ditto for design documentation: tools such as YDoc, OptimalAdvisor (the tool formerly known as Pasta) and others automatically derive design information from the codebase, reducing the need to produce copious reams of spurious and doomed-to-be-obsolete written documentation.

There are a whole swag of other XP concepts which would also work well in a classroom environment (e.g., Continuous Integration, automatically enforced coding standards, week = iteration, etc), but I would triage the four major point above to the top of my list given the opportunity.

Now, if only a teaching position came with a consultant's salary :-)

Posted by Andy Marks at 09:58 AM | Comments (1)

August 07, 2004

Never Mind The Bollocks - It's The Agilisti!

I don't claim to be a music afficionado by any stretch of the imagination, but whilst pondering the meaning of life today, it occurred to me that there is more than a passing similarity between the growing popularity of the Agile development movement and the rise to popularity of punk rock in the late 1970s.

Now before you dash off to click on the penis enlargement link that has by no doubt attached itself as a comment to this post, think about this a little...

Punk music primarily developed as a counterpoint to the predominance of pretentious big-hair, stadium rock that was so popular towards the end of the decade in question.

Agile development primarily developer as a counterpoint to the predominance of heavyweight development processes abounding in the development space in recent years.

In both cases, there were bleeding edge practitioners who's efforts were largely unrecognized because they were so far ahead of the curve, but who are now revered as minor deities in their respective circles (think MC-5 and the likes of early Kent Beck and his fellow band of Smalltalkers).

Similarities can also be found in their respective attitudes towards their craft: both camps exhibited/announced a strong desire to tear away the unnecessary baggage attached to their subject and reduce it to it's base elements. Simplicity and purity of expression was/is valued over style and showmanship.

In both cases, the rise of these new forces triggered a large amount of fear in their respective populi. Both sides were/are derided as charlatans and heretics.

So what does drawing this long and tenuous bow of similarity give us? Well, possibly nothing, but if you reflect on the genesis of the punk movement (and believe this load of hogwash), it might shed some light on where the Agile methods might end up in 5 years time or so.

So I'm quite happy to accept that punk rock looked upon overblown stage-produced light shows, dry ice enshrouded stages and 10 minute drum solos in the same way the Agile community looks upon voluminous documentation, year-long projects planned down to the quarter hour and architectural blueprints signed off in triplicate before a line of code is written.

Given this, the tried-and-true Ramones song-writing philosophy of "4 count intro, verse, chorus, verse, chorus, chorus, finish" (all within 3-4 chords and 2-3 minutes) which so epitomizes early punk rock is really their way of doing "the simplest thing that could possible work" :-)

Posted by Andy Marks at 07:04 PM | Comments (1)