I’ve noticed people avoid dealing with build issues, to the point where it seems to be a phobia. Tweaking Ant scripts isn’t much fun (not least because Ant is so poorly designed), but at some point it’s necessary to bite the bullet and sort out your build issues. Your build is part of your software, and if it’s slowing you down in a big way you need to do something about it.
I’ve noticed a pattern in which people regularly over-commit to work and consequently regularly under-deliver, and don’t seem able to break the cycle. In fact, their actions seem to perpetuate the cycle.
When you estimate how long something will take, about half the time it should be done early or on time. Almost anyone reading this will know things are rarely done sooner than expected, especially if they’re difficult. People have been shown experimentally to be poor estimators, with a marked bias towards underestimation of time required to complete tasks.
When you need someone else’s help, rather than interrupting them when they’re working, try hovering nearby waiting for them to talk to you when they’re done with the task they’re working on. It’s tempting to interrupt when what you’re working on is urgent and is blocked waiting for their help, but remember that they may already be working on something urgent - you just don’t know.
Today I discovered my current clients (who are using Fit to write acceptance tests) are implementing the Fit test support as the last task before completing the story. This is backwards. There are several good reasons why getting the acceptance test(s) running first is better.
When using Hibernate, it’s useful to include an integration test that builds an object model, saves it and retrieves it from the database. What frequently causes problems when using Hibernate (or object-relational mappings in general) is that 3 different things must be kept in sync:
A patchy test suite is a common occurrence on projects. The application is often only as good as its weakest area (though it may be weak in an area that is seldom used). The weakest area is likely to be worst tested.
For years I’ve been talking about “working from beginning to end”. It’s a common pattern in systems I see that developers begin to code functionality from somewhere other than the entry point to a system (e.g. the GUI). This approach increases integration difficulties. If the programmers keep saying things are done when they don’t actually work, this may be what’s going wrong.
The morning stand-up meeting is one of the well-known features of XP (though oddly not a “practice”). A few years ago I worked for Connextra, one of the XP pioneers in the UK, and over the years I’ve come to realize there was an important difference about our stand-ups - something I haven’t seen anywhere else.