Code Comments are they really pungent?

XP tells us that comments are a bad coding smell indicating that some functionality should be refactored out into a method. I've never been totally comfortable with this and Matt Stephens as posted a very good article as to why.

Comment judiciously, refactor if needed, avoid the 'f' word

Is Pair Programming really working for us?

Nicholas and I are having some misgivings at the moment about whether Pair Programming is all it's cracked up to be. We're not sure whether we're in danger of becoming dogmatic about enforcing it.

One problem is that in our environment requirements and demands on time can be quite fluid, especially as the development team also help our SMS API customers with their integration. This inevitably leads to pairs splitting and less optimal work sessions.

Another is that people are not created equal, there is inevitably a leader in any pair. This can be down to having more development experience, more experience of the part of the system being worked on or just having a more forceful personality.

This translates into a less than optimal contribution from one member of the pair. Especially in the latter case, the less forceful person is likely not to be contributing anyway near to their potential if they're being 'bulldozed' by the stronger party. This isn't necessarily down to arrogance or any malcious intent, it's just they way people are.

So what's the alternative?

We're going to trial working in pairs but on coding two tasks, ideally related to each other, individually. That way you have someone available, on your wavelength to discuss design decisions, patterns, tests, etc but you can knuckle down and get some tests written and functionality produced at your own pace. When you're ready, then you bring in your pair for a review.

This stays true to the concepts of discussion, collaboration and while the code reviews are notquite inline, they are very close to it.

We're running this as an experiment until Christmas. We'll report back

Protocol Therapy

An entrepreneur is required to wear many hats. In my case that can be anything from reviewing operational performance, developing new marketing channels, discussing finances with the rest of the board, to even sometimes sales.

For me this is part of the appeal of what I do. I'm better at starting things than I am at finishing so moving between different demands on my time keeps my work fresh and exciting. Though like everyone, I have to make sure there aren't too many plates spinning.

Recently however, I've been making a bit more time for the technician in me and doing some development. I've been investigating various services and protocols, building test systems to assess their potential to be offered as new services for our clients.

I've discovered that I find protocol implementation quite therapeutic. Give me an RFC, Visual Studio and a copy of NUnit and I can zone out for several hours.

Unit testing was made for this kind of development. I get lost in the mesmeric cycle of

1. Identify requirement in RFC
2. Write test for requirement
3. Write code to make test pass
4. repeat

The outcome is a robust implementation that meets the spec. as well as a general sense of well being.

Obviously I have to ration this kind of therapy, I have got a company to run, but it shows that relaxation can be found in the most unlikely of places as entirely personal.

To find mine, I just had to embrace my inner geek.

In an Extreme Programming world don't forget the value of traditional QA testing

When Extreme Programming is embraced, it is tempting to get carried away with the power of unit-testing.

If you're unit-testing everything across the whole build then surely everything should work. It is important to remember that unit-testing, when done properly, is just that. Testing units of code for compliance against a known set of outcomes. It doesn't necessarily test system wide interactions.

The development team here have recently spent a lot of time migrating our existing transaction management from the EnterpriseComponent, COM+ based, system to the TransactionScope framework provided in .Net 2.0.

Nicholas, Development Manager, as described the detail of the issues we've faced in his post: Transaction Scope - Hopes dashed. It has been horribly dissappointing, the performance profiling we did showed a big improvement, the deployment process was simplified. Everything seemed perfect.

The key to writing effective unit-tests are focusing on the unit itself and the logic in that unit and nothing else. This makes the test very quick to run, meaning you can run a full build, with tests in a short enough time to make you prepared to do it regularly.

But proper Quality Assurance testing picked up these issues. It wasn't until we ran these system wide test that the issues materialised. Generally this leads to further unit-test to ensure the issues don't materialise. Although in this case we decided to back-out this set of changes.

So unit-tests are an integral part of what we do, but good old grunt work testing is still the last, and most important, line of defence.

Paralysed by Design

We had a great example yesterday of the beauty of thinking in an XP (Extreme Programming) way about development.

We were making some changes to our billing system to add some improvements and flexibility around our contract billing processes. Very quickly we got into what-if after what-if and couldn't see the wood for the trees.

Remembering the KISS (Keep It Simple Stupid) principle we identified some new features required as well as some refactoring in order to simplify what we had in place.

We'll probably still have to solve some of the what-ifs we came up with but we can worry about them when we absolutely know we have to deal with them. We'll also have a cleaner and simplified system upon which to work. It's also amazing how many of what-ifs won't be issues when we come to them.

Velocity maintained, system better for it.

Training in the art of extreme programming

One of the challenges we face when new developers start with us is introducing them to the wonders of Extreme Programming (XP).

For the un-initiated, XP is a set of development principles and methodologies first formalised by Kent Beck in his book Extreme Programming Explained.

This approach to development has dramatically reduced our defect count so when we release new features into our system they just work. This has served to increase confidence in our service not only with our customers but also internally. Our sales and customer support teams know that they are unlikely to be fire-fighting on the front line while the technical teams are fixing the latest release. I'm not saying nothing ever goes wrong, but it is most definitely the exception.

All this has been achieved while maintaining the agility of the development team. They can respond quickly to requirements or enhancements within weeks rather than months. Given the complexity of our system now, multiple message formats, routing features, multiple languages, multi-currency billing, real-time monitoring, etc, etc this is great news for the business.

We can add new services and features without breaking the existing system.

However, this isn't possible without a very different development approach. Pair Programming is probably the most obviously different element. This is whereby development is completed with two people side-by-side on the same computer. But Test Driven Development, the The Planning Game and the other practicies can all be quite daunting for someone new to the approach.

We have a couple of new developers starting with us in July so this is particularly pertinent. Previously I have thrust a copy of Extreme Programming Explained into the hands of the new guys and then immersed them in the process straight away. Nicholas, one of the senior members of the development team, has found an alternative in the book Extreme Programming Adventures in C#. He's highly recommended it as a book that explains how as well as why in the context if C# development rather than something more abstract.

So I'm off to buy some copies, will let you know how we get on.