« November 2004 | Main | January 2005 »
December 29, 2004
The Playlist Meme (cont'd)
OK, for those who joined us late, here are the rules:
- Open up the music player on your computer.
- Set it to play your entire music collection.
- Hit the “shuffle” command.
- Tell us the title of the next ten songs that show up (with their musicians), no matter how embarrassing. That’s right, no skipping that Carpenters tune that will totally destroy your hip credibility. It’s time for total musical honesty. Write it up in your blog or journal and link back to at least a couple of the other sites where you saw this.
- If you get the same artist twice, you may skip the second (or third, or etc.) occurences. You don’t have to, but since randomness could mean you end up with a list of ten song with five artists, you can if you’d like.
And here's my results:
| Artist | Title |
|---|---|
| Adrenochrome | The Sisters Of Mercy |
| Ban Everything | Jello Biafra (Spoken word) |
| Charlotte Sometimes | The Cure |
| I Remember You | The Ramones |
| Mint Car (acoustic) | The Cure |
| Numb | The Cure |
| Color Me Once | Violent Femmes |
| Be Aggressive | Faith No More |
| Enjoy The Silence | Depeche Mode |
| Every You Every Me | Placebo |
Overall, I'm pretty happy with this little random look into my musical tastes - I think it's captured the overall quite well. Suitably pretentious without dredging up any unfathomably obscure references or anything from my Best Of Madonna CD, which I do treasure.
Posted by Andy Marks at 07:11 PM | Comments (0)
Stupidity +/- 100%
Reading a very interesting recent blog from Robert Watkins about the difference between degrees of accuracy and confidence when performing estimation, I was reminded about a cosmically bad assumption I was party to during a high level estimate our team make a project or two ago.
This estimate came from a multi-day workshop to thrash through some the issues confronting us for the second major phase of a development effort we had just moved into production. We had been locked up in a room with the PM and a couple of BAs ploughing through a 20 page list of one-line requirements that would be fleshed out/decomposed into the story cards for this next phase.
For each line item, we attempted to gather as much extra information from the BA, equate the litem with work from the first phase where possible (using our list of actual time spent against each story), and then generate a high level estimate in order to give an overall figure to the development effort for the entire phase.
Along with the estimate came a level of precision, which varied wildly against our ability to equate the line item with previous work, and it's associated actuals. And herein lay our problem...
We had been using a percentage figure to give shape to our precision values. In other words, a line item which was just another instance of something we'd already developed would have an estimate along the lines of 2 days +/- 10%. For the completely foreign items, it may be something like 2 weeks +/- 100%.
And it never occurred to me until a collegue who has probably forgotten more about project management and estimation than I will ever know pointed out the implicit assumption whenever you use percentages as units of precision. A percentage is inherently bounded. By definition, a percentage cannot exceed 100 in either the positive or negative direction. Sure, people do abuse the concept with terms like 110%, but the fact remains that people naturally think of a percentage not being able to exceed 100 - as if the mere application of the term has suddenly implied a mathematical constraint to the reality where none existed previously.
The big problem waiting to happen with our use of percentages is the reaction from all and sundry when one of the unknown items turns out to be much, much bigger than we had anticipated and a 2 week +/- 100% estimate becomes 6 person weeks of implementation. Suddenly our worst case estimated scenario (4 weeks) was still way too optimistic.
Thankfully, we never had to stand by these estimates, so our mistake never had a chance to bite us further down the path. Hopefully, everyone involved has learnt from the potential calamity our actions could have caused. Thanks to the excellent "Walzing With Bears", I am now much better equipped and prepared to deal with these situations.
Note: we had not made any attempt to document our level of estimate accuracy in this process. As detailed in Roberts' log, adopting this approach could also have helped alleviate any false expectations set though the use of percentages for our precision units.
Posted by Andy Marks at 07:19 AM | Comments (0)
December 25, 2004
Is your build broken, Broken or BROKEN?
As with most Agile development teams, we use a token to villify the most recent team member to have caused our CI build to fail. In our case, it's a rather Academy Award-looking figurine of one of the Teenage Mutant Ninja Turtles (not sure which one), and the ceremonial handing over of the token upon a new build breakage is something we take rather more pleasure in than we probably should.
Our record on clean builds tends to vary quite significantly; we'll occasionally run green for most of an iteration, but we also have extended periods of almost perpetually broken builds, which causes no end of constenation to our long suffering build manager.
Recently, there have been a few debates over the semantics of a "broken build". Quasi-hypothetical scenarios along the lines of "what if I break the build, realise it and then correct the problems before Cruise Control starts another cycle... does that count?" are put forth to determine whether the token is able to be passed to a new owner or not.
I tend to stay somewhat tangential to these discussions because, to my mind, the underlying issues with a broken build are three-fold:
- In the case of a failure in some part of the compile/deploy cycle, the broken build can immediately and completely stop a developer from continuing to work.
- In the case of regression as seen through test failures, the broken build can prevent the application being released at the end of an iteration.
- In the case of a stylistic failure as reported by Checkstyle, Clover or the like, the broken build can be an indication of a deeper issue around some area of the codebase.
Obviously, the first of these cases is the most immediate and costly. The worst case in this scenario is a broken compile caused by (for example) a new file that was missed in a commit, coupled with the developer leaving the office for some period (e.g., heading home early, holidays, etc).
The effects of the second case can range from severe to mildly annoying, depending on the proximity of the iteration close and/or the amount of overlap in the areas of the codebase covered by different developers. Occasionally, a test failure initiated by one developer can hide a problem in another story, if that story is in the same neighbourhood of the codebase.
To my mind, the third case (i.e., stylistic problems), although it can indicate deeper problems in the system's design, is by far the least worriesome of the three categories and therefore should be considered "the lesser of three evils" in this company. I know of some people who move Checkstyle and similar such checks to the end of their CI build cycle, thereby preventing such problems from overriding the more pressing issues of syntactic and semantic correctness, as gauged via the build process itself and the test suite respectively. Although such a move does violate the "fail fast" doctrine, it does appeal to me from a triage perspective.
Posted by Andy Marks at 09:41 AM | Comments (0)
December 10, 2004
Project Manager or Project Coper: Errata
A couple of minor clarifications to my previous post:
- When I said "I'm happier working with a Project Coper", I should have made it absolutely clear that this preference is in relation to working with a Mismanager. Of course my ideal is to work with a proper PM, but IMHO the Project Coper is the lesser of the two other evils.
- After some further thought, I retract my statement about Copers and Mismanagers being perpetually mutually exclusive - I actually believe that under duress to exert some "control" over a project, the erstwhile Coper will quickly adopt Mismanager-type behaviours.
Posted by Andy Marks at 12:35 PM | Comments (0)
December 08, 2004
Project Manager or Project Coper?
I've been in a very dark place work-wise of late, so I've been reflecting a lot on my previous work experiences looking for various patterns that might shed some light on various forms of organizational behaviour that seem to get right up my clacker. The result of one such musing is the demarkation of PMs I've worked with into three groups; Project Manager, Project Mismanager or Project Coper.
A Project Manager is someone who spends most/all their time actively managing the project in the traditional sense. As such, most of their time is spent dealing with the bureacracy incumbent in most organizations and generally running interference for the development team.
A Project Mismanager is the Dilbert-style PHB from Hell. Still an active participant in the life of a project, the Mismanager devotes their time to micromanaging the development team or otherwise getting in their way. Their projects tend to happen despite of them, rather than because of them.
A Project Coper is little more than a PM facade. Although they have the title, it's certainly not a position they devote much time to and when they do, it's usually in a very reactive manner. Any correlation between their behaviour and the outcome of the project is purely coincidental.
I've had quite a mix of these three types during my professional life so far:
Project Manager: 4 instances
Project Mismanager: 1 instance
Project Coper: 5 instances
Curiously, my experiences show a strange correlation between people's first names and the Project Coper role, although I'll keep the names private to protect the guilty.
Overall, I'm happier working with a Project Coper as they tend to keep out of my way. I also suspect that Copers and Mismanagers are mutually exclusive at a genetic level, although the Mismanager probably has ambitions/deceptions of ascending to true PM status.
What are other people's experiences? Have you been besieged with PMs of one type or another? Do you see a correlation between PM-quality and your level of morale on the project?
Posted by Andy Marks at 04:04 PM | Comments (0)
December 04, 2004
Pair Programming Workshop at XPDay 2004
This is just a quick recap of the workshop I gave at XPDay 2004 in London.
From my own perspective and from the feedback I received from the participants after the workshop, I was really happy with how the session unfolded. In short, the 90 minute workshop consisted of:
- A quick 20 minute spurt of the theory around the role of Agile Coach as Change Agent, introducing XP into an organization or development team inexperienced in XP
- A 60 minute pair programming competition undertaken by the audience, working to complete a set of supplied acceptance tests for a written specification and a set of skeleton implementation and utility classes.
- A quick retrospective/summary at the end.
The biggest fear I had coming into the competition was that the set problem would be too big to finish completely within the allocated time and, as it turned out, the fear was well founded. Unfortunately, none of the five pairs in the competition successfully implemented all 5 acceptance tests, but the conclusion did see an exciting dead heat with three of the pairs having implemented the same number of tests at the end of the 60 minutes. The winner was decided by my co-presenter Joe Walnes, who did a quick inspection of each of the solutions.
The quality of the pairing was extremely high. Although most of the pair were formed on the day, they exhibited many of the signs of successful pairs from the outset. With each member equally unaware of the requirements until the beginning of the competition, there was an immediate need for the pairs to rapidly digest the specification which helped get the intra-pair communication flowing rapidly.
Joe and I, in our duel roles as on-site customer and coach, were very impressed with the ongoing communication, frequent driver/nagivator rotation and mix of tactical/operational thinking exhibited by the pairs.
The main points I took away from this exercise as Coach, based on observation of how the pairs tackled the exercise, were:
- You cannot overstate of the importance of incremental design enough. The acceptance tests were ordered in such a way as to promote a naturally evolving solution, yet a couple of the pairs still adopted a Big Design Up Front approach to get to the complete solution in one foul swoop.
- Knowledge of the available API can make a vital difference in developing quality working code to aggressive schedules. Several pairs lost quite an amount of time implementing functionality that had already been provided in the supplied code base. This was probably my biggest regret as we could have saved a lot of this time with a quick "make sure you look at the supplied code" type announcement up front.
The other mistake I made in planning the session was to underestimate the effort required to context-shift from being in a highly interactive, highly communicative mode back to a more passive one. For this reason, I basically gave up on the retrospective aspect of the workshop as it was obvious the audience was getting far more benefit from continuing to discuss the exercise amongst themselves rather than listen to me lead a more structured wrap up.
Ideally, I would have loved to conduct this workshop over a 3-hour period instead of 90 minutes, allowing sufficient time for a (slightly) juicier exercise and a fuller retrospective at the end.
Again, thanks to everyone who participated (especially Kent and Riaz, our VB developers who ended up winning the competition - sorry for the blurry photo guys) - I hope y'all got as much out of the exercise as I.
Posted by Andy Marks at 06:21 PM | Comments (0)