August 26, 2004
It's the little things...
I've been bitching to my team lead lately.
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:
- To my knowledge, there is no downside from having unused imports in your classes from a performance perspective
- 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.
- 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.
- 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).
- 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.
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:
- What knowledge do you have of the risk management processes used on your project?
- Have you ever seen the risk list generated by the risk management process?
- Is this list located in a position visible to the entire development team?
- Is this list revisited/updated frequently throughout the course of the project (i.e., are the risks tracked?)
- Do you know what happens to the estimates you provide to your project manager? Do your naturally optimistic figures get presented as schedule commitment dates to the stakeholders? Or does your PM use them as inputs to a risk model, thereby deriving a more realistic project schedule using a generated uncertainly diagram?
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.
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:
SpikeXP 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!
IterationsShort 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 TestingAlthough 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.
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...
- 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.
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:
- Students are naturally bad at requirements gathering and analysis. It's generally not their fault as these skills come with age and experience. The current solution: specify requirements explicitly up front.
- Likewise, software design is also a skill that is difficult to "teach". I think we develop an eye for good/poor design through exposure to sufficient amounts of both. At undergraduate level, design is usually imposed from upon high for these reasons. Little scope is provided for reflecting on qualitative differences in implementation.
- Assessing individual acquired knowledge over the course of a subject is difficult given the ease with which software can be copied, modified and re-distributed. Traditional formal assessment techniques like exams are a poor indicator of a student's ability to develop software. Further complicating this issue in most computing degrees is the large number of students from countries where the cultural norm is for most learning to be done in private study groups.
At my university, we placed great emphasis on one-on-one student interviews at the end of each subject to accurately determine how much each student has taken on during the subject.
- Students, like professional developers, have an active dislike for documentation in all forms. They have an inherent sense for the YAGNI nature of this form of deliverable. Therefore, requiring traditional documented deliverables for specifications and test plans is problemmatic.
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
nis 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.
- Ensure tutorial sizes are roughly
- 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 :-)
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.
- Like the punk movement, the Agile camp has split into distinct elements; DSDM, Scrum, XP and the rest are the equivalents of grunge, industrial, gothic rock or any of the other bastard children of the punk family tree.
- Many of the Godfathers of punk are still in the scene. Although the Ramone family is diminishing with each passing year, John Lydon, Jello Biafra, Henry Rollins, Iggy Pop, Lou Reed, Nick Cave and Mick Jones are still out there, to a greater or lesser degree. One would assume that, given the unlikely occurrence of non-caffeine substance-abuse within the Agile community, Uncy Kent, Martin Fowler, Ron Jeffries, Ward Cunningham and the like will still be around in the industry in the next 20 years.
- Perhaps the most encouraging sign for those struggling to introduce/champion Agile development at the moment is the fact that punk rock has, with a few exceptions, been completely integrated into the music industry and few people even blink twice at the punk bands of today.
- As a caveat to the above statement, people adopting these epithets can occasionally loose sight of the very reason these movements began in the first place. At the risk of offending their fan base (and being bludgeoned to death by pack of skateboard-wielding youth), bands like Offspring, Alien Ant Farm and probably a whole posse of others can be considered punk in name but not in spirit. Similarly, you do tend to come across people who talk the Agile talk, but definitely don't walk the walk. Likewise, a puritanical Agilist with no desire/ability to reflect on the underlying reason for their actions is as bad as the blinkered heavyweight process weenie who just cannot come to terms with "that awful racket those kids are into!".
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" :-)