Guerrilla Developers

Not sure I like the punchline but the story is real.

Once upon a time there was a project, pretty bad one actually. The were big performance and stability issues. The were no docs about functionality whatsoever. The code base quality was disastrous. There was even a local framework implemented that dealt with mapping java classes and fields into database tables via annotations (hmmm… this kind of framework does sound familiar…)

Several smart developers where thrown into this project. Officially, they didn’t have time for technology upgrades because new clients were waiting for this software. Developers couldn’t deal with the crap they ended up with. They started guerrilla development. All the efforts occurred under the radar: refactoring, automated testing, improving migration scripts, performance & debugging capabilities. They were stealing work hours, cheating on estimates, doing 2AM check-ins, staying late at work, etc.

After ~1 year of guerrilla development developers finally sorted out the project. Cost of introducing new features was reduced substantially, migrating new clients was blind fast, there were very little bugs, fixing & patching the production system was quick & easy.

Higher management was very happy with the quality of the product. The project was doing well and apparently it didn’t need so many developers to maintain it. So they rewarded developers… by transferring them into even worse project. The project was bigger, uglier and had large number of existing team members that stopped caring long time ago. Half year passed and there is no sign of improvement. Guerrilla developers are pretty much disillusioned because there is no groove in the team for sneaky improvements plus they still remember the reward after fixing similar project last time…

//given //when //then forever

@Test
public void shouldDoSomethingCool() throws Exception {
    //given
	 
    //when
 
    //then

}

I like to call it the Ultimate Test Template. I’m so fond of those 3 little comments but surprisingly, I didn’t buy it at first. Micheal (it’s you, tapestry-maven-iPhone fan boy =), friend from ThoughtWorks showed me it a couple of years ago. Actually, he didn’t show it to me – I just overheard him coaching a young dev about it. That day I thought I didn’t need any hip comments because my tests were great anyway. It was foolish.

Don’t be a fool like me and start writing //given //when //then today. Life is too short for messing around – you want to get level 85 in software craftsmanship soon, right? Here’s the deal: use the template for 1 iteration and if you don’t like the results then I will give you your money back. Seriously, no matter what you think about it – buy it! BTW. If you need to document some ‘exceptional’ behavior in your test somewhere there is the template for tests with exceptions.

Lately, I’ve been selling //given //when //then quite relentlessly. I even try to sell it via Mockito api. (The link also shows how to install the template in Eclipse so don’t miss it!)

I tried to lobby for the Church of given-when-then in Krakow, Warsaw & Kiev. I heard rumors that Wroclaw develops a growing number of brothers and sisters in faith =)

I think I forgot to thank Dan North for given-when-then and Liz Keogh for the idea of BDD aliases in Mockito. There you go!