Rather than waiting for somebody important decision maker to make the perfect decision, the people actually working with the problem must be given the responsibility to make snap decisions. Most of the time good enough is far better than nothing anyway…

Remember: It is always easier to ask for forgiveness than ask for permission!

By introducing CruiseControl or other continuous integration tools, you also have the opportunity to introduce the concept of “peer embarrassment”. When someone delivers their code, the continuous integration tool kicks in to do the compilation, code analysis, run unit tests etc. and finally the build results are mailed to all the developers.

In case of a build failure it will be clear to everyone who broke the compilation, tests, violated coding standards or whatever went wrong. This is embarrassing for the developer and he/she will probably try to avoid this the next time…

Be aware, though, that there is more than one way of avoiding mistakes. One way is to do the things right, for example by ensuring that all tests are running with green bar before making a code delivery. Another way is to cover you ass by neglecting to write tests or, even worse, removing failing tests before delivering…

The assumption that a heavier methodology with closer tracking and more artifacts are “safer” for a project than a lighter methodology wit fewer artifacts has developed over the years. This heavier-is-safer assumption is often caused by the fear project managers experience when they get to far away from the code. Since they no longer can determine the state of the project with their own eyes, they tend to introduce more reports, decision points, coordination, meetings etc…..as opposed to trusting people…
Alistair Cockburn discusses some constraints in methodologies that add more burden than safety in his book “Agile Software Development”. This book is good reading!

Have you ever experienced that a project manager comes running asking “What is wrong?” when you are sitting there peacefully pair-programming?
Whenever one or more people are discussing something, maybe even (God forbid) using a whiteboard, managers tend to think that there are som serious threats to their precious project.

People working together should be seen as a good thing!! Two people working together on a task means four eyes and two brains rather than two eyes and one brain. To avoid unnecessary noise on your project, some efforts must be done to convince project management of this. Otherwise you might find yourself in a situation where problems are being created out of nothing. Project managers love problems. I guess it gives them an excuse to why their projects fail…

I tip of advice I got when I recently attended the Øredev conference was that rather than calling it pair-programming, you should call it “Continuous Peer Reviews” when selling the idea to the management… 🙂
Comments(0)