Assert First Development

A good programmer writes about 10 lines of code a day. Maybe less maybe more, though it's a very interresting topic leading to names like Barry Boehm and Tom DeMarco, it's not the subject of this post. I just wanted to point out that eventhough undoubtedly useful, IntelliSense, or any autocompletion tool for that matter, is way overrated. A programmer might type in that single line of code of the hour in five minutes, or in eight without IntelliSense. I'm glad we've got that out of the way. Next, if you are a TDDer and don't already use the Arrange/Act/Assert concept, start today and you will never look back. Anyways.

"Assert First Development"[1] is about writing the assert of your test first. This gives you the means to write the act-part in a way your assert needs it, and then the arrange-part as your act and assert needs it. This way you have to think about only one thing at a time. If you do it the other way around - that is from arrange to assert - you always have to think about all three parts simultaneously. You could of course say "I'm very smart and I can think about many things at once", and I believe you can, but you could use all your cleverness to solve one problem at a time, potentially solving things even better. If not, you still haven't lost anything, you just did your job sequentially. But chances are that your assert will be right the first time around, not mentioning your arrange in which you set really only those things up your act needs, and not the things you think your act will need. Only thing you lose is some parts of your IntelliSense, but we already established that it's really not that much of a loss.
One last thought. Assert First Development is another great example of the pull-system: there is never waste produced, we don't setup mocks or fakes or anything we might not need eventually.

References:
[1] Kent Beck: Test Driven Development: By Example

Read full post...

Problems With And Without Honesty

Without honesty there are a tons of problems. It's easy to see why Beck (not again?!) advocates openness and transparency in software development: in short, if we talk about issues honestly we stand a much better cance to resolve them. It's easy to see, but very difficult to realise.
Difficult because of the only problem with honesty: our self-esteem.

More specifically the From and the To part of honesty. The difficulty with the From part is manners and custom. We have a hard time telling our colleague he screwed up badly or has not the first clue what he's talking about, because that's what we are all used to: the not-telling. And because we could be and many times have been at the To-end of honesty and we know first hand how it feels when our mistakes are pointed out. From or To: our self-esteem gets in the way.
In retrospectives mature teams have the strength to be honest about mistakes, as I mentioned before. But it's a lot easier to tell honestly and to be told honestly about problems, when you are team. This is not to underestimate the power of collective responsibility, actually this is to encourage teams to try. You will be susprised how much more honesty you can handle as a team.
However. A team's straightforwardness is not invincible either. At the end of the day the team is made up of individuals, and their willingness and inclanation for honesty ultimately will draw the limits of the team's honesty. Team-members will have to intentionally put aside their self-esteem and pride so that the team can go the distance with honesty, can find real issues, real solutions and once again the team can improve.

Read full post...

Your Choice

Here's the deal. The last post wasn't much of anything. I know. The reason was that there are a couple of things I want to write about, but couldn't decide which one to pick, so I wrote about something I didn't really want to. Anyways, now is your chance to decide what the next post should be about. Vote on the right, comment below, if and when.
Read full post...