« August 2005 | Main | October 2005 »
September 25, 2005
A Hammer your only tool? What if it suddenly tripled in price?
Last week I was speaking with a co-worker on my current project and we were both bemoaning the overuse of overtime and death march-type working hours as the universal panacea for poor project management in IT projects. So often it seems, the first (and presumably only) solution that occurs to project management is to pull the "do more" lever (i.e., work longer). We were both of the opinion that whilst it is relatively straighforward to produce something out the other end of the project when the entire team has been working 60+ hours a week for the last year, the real skill is in delivering on time under more normal working conditions.
As it turned out, my co-worker had been thinking longer and deeper about this problem and had a very simple but novel solution that, whilst not addressing the issues of projects going badly off the planning rails in the first place, will at least help IT project managers everywhere consider other solutions when the proverbial hits the fan and they start reaching for the "do more" lever.
In short, his solution was to insist on paid overtime for all project staff (be they permanent staff or outside contractors). His reasoning is that once every ounce of overtime appears within under the costs of the project, and therefore the direct responsibility of project management, the "sweatshopping" of IT project teams would cease to be such an attractive proposition, once it was no longer something that could be swept under the fiscal carpet and effectively have a zero cost* for the project team.
Hopefully the thought of insisting everyone work weekends for months on end will be a true last resort if the result would be to increase the overall project expenditure by 50%! Perhaps then solutions which address the real underlying issues for the project's woes be considered if they can be quantified and objectively compared to the cost of the the "do more" lever.
* Like most people, I believe that demanding extended periods of overtime does come at a cost to the project, although not one that can be easily quantified up front. Productivity reduction, poor morale, increased sick leave and resignations are all factors which have a slippery but very real impact on the running of any project.
Posted by Andy Marks at 06:15 PM | Comments (3)
September 17, 2005
Why I Love Testing Command Objects
Classes following the GoF Command pattern are readily suited to easy unit testing:
- By design, they are naturally Dependency Injection friendly, usually via setters
- By design, they typically only need testing directly at the
execute()method
Now there are probably plenty of other patterns lending themselves to easily testable solutions, but I've been concentrating on Command implementations recently, so they've got my focus.
The general pattern I use for my (JUnit) unit test methods is test<MethodUnderTest><Intention>. For example:
- testValidatePasswordFailsWithPreviouslyUsedPassword
- testPopulateAccountMatchesNameAndAccountNumber
As you can imagine, some of these method names get rather long and I'm constantly fighting a battle between clarity and brevity. But when it comes to testing Command implementations, the MethodUnderTest part of my method name just disappears, given that execute is usually the only accessible method worth testing.
Love it!
Posted by Andy Marks at 03:50 PM | Comments (3)