When Agile methods were first emerging, their proponents claimed that everything was going to be simple: we code units and the unit tests to test them, and the Customer writes acceptance tests. If the tests pass, it’s done.

Later came the understanding that the Customer is seldom able or willing to write any kind of formalized code. Still, the testing was necessary, and so either the programmers or the testers have to do it. Read more

Content migration is never easy, and can sometimes be tricky and even downright messy (for some good reasons). In fact, the content migration can be the hardest part of implementing a new CMS.

Having contributed to some challenging migration projects for one of our European clients, I’d like to share a few practical tips on how to make life a little easier for teams involved with particularly large and demanding CMS migrations. Read more

Everybody likes statistics. Having a bunch of numbers to look at or to manipulate gives you the feeling of being in control of things, or at least of having a grasp on reality. So when a manager asks me what our average cyclomatic code complexity is today, I don’t blame him. Still, I respond by asking why he wants to know.

I think I might literally roll on the floor laughing if I was told, for example, that we have too few lines of code (I heard a story about that once, and I hope the person who told it was kidding). But you do hear quite often that according to the contract, our test coverage should be above 90%, or that the maximum value of MCC should be 10. And that makes me sad. Read more

Many fans of Agile love pair programming. Tons of articles have been written on all the good things it can bring to a development team. However, if misused or allowed to get out of control, pair programming can do serious harm.

Pair programming involves two programmers working as a pair at the same keyboard, one “driving”, i.s. writing code and explaining why certain statements were used, etc., and the other “observing” –paying close attention to what is happening on the screen and providing early feedback. This approach enables early discovery of obvious design issues, before the code is even first compiled. Read more

Anyone who has ever managed a software development organization will agree: time tracking is a pain in the neck. It’s difficult to get people to fill out time sheets, or otherwise submit their hours into some kind of system. Developers see it as a boring and irritating activity that is also invasive: people just don’t like to be tracked, and if you try, they will suspect ulterior motives. In short, most developers hate time tracking with a purple passion.

But what if you really need time tracking? Well, all is not lost. Read more

Over the years, I’ve been involved in a lot of discussions about how to estimate during sprint planning. If you’re new to Scrum – or even if you’re not – I hope you can find value in these musings.

Story Points. There are some very good reasons to estimate in story points rather than in man-hours. When you work in an Agile environment, everybody pretty much agrees that there is uncertainty to every user story. In order to claim that a requirement will “cost” 8 man-hours, you should first call in a business analyst to flesh out the requirement until it’s 100% unambiguous, and also an architect to design a solution for it. Read more