year in London, year in Thoughtworks

It’s been a year in London and a year in Thoughtworks. It’s high time to recap things:

• number of flats lived in: 2 – Limehouse (word of respect to fellow flat mates!) and Chiswick
• landlords killed: 0 – likely to change in few months time…
• family members invited to taste gorgeous London lifestyle (some people may detect sarcasm :) ): 4
• Number of OS projects contributed: 4
• games bought: 2 (Civilization IV, Football Manager 2007… jazda biała gwiazda!)
• tube strikes survived: 1
• knees twisted – 0: yupeeeee!
• cool countries visited – 2 (Spain, India)
• married the same women again: 1
• being late in returning streetcar and paid fee – 1 :(
• books bought: 9
• books read: 13 (yeah… not related to commute time…)
• IT books bought: 2
• IT books read: 1 (I know, very impressive)
• IT books started reading and fell asleep: all
• IT books started reading, fell asleep and woke up in Cockfosters: 1
• Arsenal games seen: 2
• graduated from Uni: 1
• airports toured: 10
• primary school friends found: 2
• TW projects involved: 3 (PHP, .NET, Java, and still waiting for Ruby gig!)
• english improved by: 0.015%

you break you revert

Typical build-breaker usually knows what’s wrong and attempts to fix the build by checking changed code in. Now, how many times we knew exactly why build was red after our check-in but we could not fix it quickly anyway? We needed few commits, few more red passes to finally make the bloody thing green.

I like when unfortunate build-breaker first reverts his change, lets the build go green and in meantime tries to solve famous it-works-locally mystery. However I can see 3 and only 3 exceptions to the golden you break you revert rule:

1. The team is small. Small team usually means small and easily manageable codebase, simple and stable CI process, not many problems in merging. To wrap up: not much time and money is spent if build is red.
2. Oops, I forgot to check-in new files. Everybody does it from time to time (famous ‘show unversioned files checkbox‘ in tortoise should not exist or at least should be hardcoded to true), there is not point in reverting – just check in missing files. It’s always worth looking why the build failed and see whether there are any cannot-be-resolved-to-a-type compilation errors (oh, that’s java =).
3. Cannot really reproduce the problem locally. CI environment is usually different than local (different OS, etc.) and that can cause problems. Sometimes it’s better to check the fix in since you cannot reproduce the problem locally anyway. However, if it’s possible to test the build in CI environment before checking in, than I would definitely do the revert.