« March 2005 | Main | May 2005 »
April 30, 2005
The Curse of the Early Adopters
(This will only really make sense to Australians - or non-Australians with a very keen sense of weather patterns)
I rushed out to buy Tiger, the new version of Mac OS X last night and installed it as soon as I got home. One of the new features I was looking forward to was Dashboard, the widget framework based on Konfabulator which I'd been using recently. In particular, I'd taken a shine to the weather forecast widget in Konfabulator and knew Dashboard had an equivalent.
Imagine my surprise then when I saw the forecast weather in my home town Melbourne, and that of my previous home town, Brisbane, some 2000Km closer to the equator!
Posted by Andy Marks at 06:32 PM | Comments (1)
Joel versus the Agilisti
Joel On Software is one of the several blogs I try and stay on top of - mostly because I really relate to his pragmatic approach to software development and the issues on it's periphery. So it was with some interest that I read The Joel Test, a 12-step process for getting a handle on how good a software team is. Now, apart the obvious bias towards developing a product which is interleaved throughout the 12 generally sensible questions, I was struck by how the Agile community might rate on his Test. On behalf of the teams I've worked with over the last couple of years, here's how we rank:
- Do you use source control? Hell yeah!
- Can you make a build in one step? Ditto
- Do you make daily builds? Honestly Joel - only every day? I'm surprised! But the test was devised in 2000 and his reasoning is solid, so I'll forgive the slackness :-)
- Do you have a bug database? Yep... not FogBugz, but not everyone's perfect
- Do you fix bugs before writing new code? Depends - is that what the customer wants? Or do they want more functionality and are willing to leave the bugfixes for now? I guess I only get a half mark for that one :-(
- Do you have an up-to-date schedule? If I'm doing Adaptive Planning, then my schedule is up-to-date as of my last iteration - guess that's a yes
- Do you have a spec? Nope, or at least not in the glossy, ring bound phone book sense that's being aluded to here. Damm - crashed and burned on that one.
- Do programmers have quiet working conditions? Bzzzzt again - now I'm in a rut!
- Do you use the best tools money can buy? Never have, never expect to - ahhh, three in a row!!!
- Do you have testers? Yep - generally supplied by the kind client, but yep. Whew - back in the black again.
- Do new candidates write code during their interview? Shoots... and scores! Yes again.
- Do you do hallway usability testing? I think I'll interpolate here and give myself a full mark here. Customer sign-off during/after the iteration is driving at the same point
So I came out with an overall score of 8.5/12, which plants me firmly in "serious problems" territory! Am I particularly fussed by this??? Not in the least. Why? Because I think Joel's got his wires crossed in a couple of respects towards the focus of this test and what the most important contributer to a successful project team actually is.
Firstly, I think the questions he poses are all excellent ways of determining the quality of a software development environment, however this is a necessary but not sufficient measure of the quality of the team(s) working in this environment. Put simply, a partially enlightened software manager could automate the build, add version control, unhook the phones etc (i.e., address all the points hinted at in the test) and then put the Larry, Curly and Moe of the development world into this shiny, quiet environment with brand spanking new machines... and no good would come of it at all!
Until a valid means of quantifying the quality of the developers themselves is found, everything else is merely diverting noise. I'll take a bunch of high quality developers over a high quality environment any day of the week and twice on Sunday. Good teams are the closest thing to a first-order determinant of a project success that I can think of, and they will naturally create the sort of environment Joel treasures in order to do their work effectively, but I wouldn't want to induce the presence of such a team by the existence of the environment itself.
Unfortunately, effectively measuring developer quality is a slippery slope and the metrics thrown at the problem in the past (line of code per day, defects per line of code, etc) are well wide of the mark. And given the anecdotal evidence of the best developers being an order of magnitude better than average developers (can someone please point me to the original reference of this fact - is it Yourdon?), I suspect those developers on the left side of the bell curve and the majority of employers are silently happy and grateful for this fact: imagine attempting to justify a 50% salary band across a development team when some can quantitatively demonstrate they are almost 10 times more productive than others! Come to think of it, I don't think the gun developers would be overly happy in this knowledge either, irrespective of how internally driven they may be - perhaps ignorance is truly bliss in this case?
But back to The Test! Even if a more Agile-friendly version of this were to be devised, I still wouldn't be particularly ready to automatically class every 12/12 team as "high quality". Joel finishes the article with four perspectives from which the test can be administered: of these, I would only consider the last two (from a potential employee or investor) to be valid uses of the test. The final phrase of the article is probably the best summation I can provide "...this test can provide a quick rule of thumb" - nothing more.
Posted by Andy Marks at 01:32 PM | Comments (1)
April 25, 2005
Risk if you do, risk if you don't
For the last couple of weeks, I've had the chance to do some "pure" consulting for a new client with a collegue of mine. The engagement is principally to advise how Agile development methods might be used on a large-ish software project that's currently in requirements analysis. The client does not have any Agile experience, but a desire to respond more rapidly to changes in customer requests and mitigate the considerable integration work inherent in all their development projects has led them to speak to my employer. It's been fascinating work for a number of reasons:
- I've never had the chance to work with this collegue before and he's a more experienced consultant than I am, so it's been good to watch him work and learn
- This is the first time I've been involved with a project from Day 0 (as far as our engagement with the client is concerned). My involvement in previous projects has always commenced well after development has started and this time I on the ground several months before the first line of code will be written in anger
- Everyone we've spoken from the client has been very interested and hugely helpful in our efforts to get a handle on the size of the project itself. The "interest" is somewhat expected, since our work could result in a huge change to the way they work, but I've been more blown away by the generous nature of the staff we've been working with and their desire to really understand what Agile brings to the table. Sure, there have been some concerns expressed for how Agile deals with issues close to their heart: the usual chessnuts of Architecture and Design (note the capitals :-)), documentation, and accuracy of estimates but they've also been quite understanding of the strengths of Agile and the potential trade-offs required, should you wish a project to play to these strengths.
The most interesting part of the initial work we've been doing is considering and documenting what form of Agile development will best suit this client. To all involved, this project is viewed as risky on a number of axes; tools chosen, processing complexity, strategic business value, staff skill requirements, etc... and to this already full pot they want to add a (potentially large) variation to their development process!
Now I'm one of the first to trumpet the use of Agile methods as a means of risk mitigation, but when the introduction of Agile itself further increases the overall risk profile of the project, how much is too much?
One possible solution is to draw the line with the current amount of uncertaintly and say any additional risk in the form of a new development process will only serve to cause more problems - the safest way forward is to not adjust any more project variables contributing to the overall sense of risk. Conclusion: no Agile.
As counterpoint, given the amount of risk already involved, the feedback provided by adopting Agile techniques (assuming the risk of their adoption itself can be managed) is vital to ensure the project stays on track, or at least come off the tracks in as noisy a way as possible as soon as possible. Conclusion: Agile all da way!
As possible, the truth lies somewhere between these two cases and the exact location of this position is something my collegue and I will be struggling to determine over the next few days.
Posted by Andy Marks at 08:43 PM | Comments (1)