Developer! rid your wip!

I’m big on eliminating waste, I’m big on minimizing Work In Progress (WIP).

Here’s my story: a colleague asked me to pair with him because he broke the application and he didn’t know why. So we sat together. My first question was:

– “Did the app work before you made your changes?”
– “Yes”
– “Ok, show me the changes you made”

I saw ~150 hundred unknown files, ~20 modified or added files. I said:

– “That’s a lot of changes. I bet you started doing too many changes at once so you ended up with a lot of WIP. Can we revert all the changes you made?”
– “Errr… I guess so. I know what refactoring I wanted to do. We can do it again”
– “Excellent, let’s clean your workspace now”

We reverted the changes. We also discovered that there were some core “VCS ignores” missing (hence so many unknown files in the working copy). We fixed that problem by adding necessary “VCS ignores”. I continued:

– “Ok, the working copy is clean and the application works OK. Let’s kick off the refactoring you wanted to do. However this time, we will do the refactoring in small steps. We will keep the WIP small by doing frequent check-ins on the way.”
– “Sounds good”

Guess what. We didn’t encounter the initial problem at all. We completed the refactoring in ~1 hour doing several check-ins in the process. Previous attempt to the refactoring took much more time due to few hours spent on debugging the issue.

Here’s my advice for a developer who wants to debug less & smile more:

1. Understand what is your work in progress; keep WIP under control; keep it small.
2. Develop code in small steps.
3. Keep your workspace clean, avoid unknown or modified files between check-ins.

Hudson is a cunning beast

Build failed today:

ERROR: Failed to update http://svn.dev.sabre.com/svn/apd_centiva2/trunk
org.tmatesoft.svn.core.SVNException: svn: blah blah blah

‘Bummer, I need to log in to the ci box and figure out what’s wrong with svn.’ – I thought. Being in the middle of something I didn’t get to it immediately. Then I got another notification from Hudson:


Updated failed due to local files. Getting a fresh workspace
...
Finished: SUCCESS

Apparently, hudson figured out that there’s been an issue with svn update so during the next build he simply did a full checkout. It worked just fine. I do like Hudson.

back to the basics

Someone is trying to convince me that I need unit testing or a customer to justify having an automatic build?

Even if I agree to that logic (but I don’t):

• For the past several years I haven’t been in project that hasn’t utilized unit testing.
• In my entire life I haven’t been in project that hasn’t got a customer/stakeholder.

That means automatic build is always a must-have. Simple.

If I had to say one reason why to automate the build I would say: ask google. Smarter people have already wrote about it.

Ok, I admit, I recently hacked out a small swing app for home usage. And I didn’t bother to cut a build script =) Still hoping for afterlife in agile heaven though =)

Build Bat AKA Build Whip

Any fella who cares more about the build than the others. Here is bunch of properties of such build whip.

• Has extraordinary level of focus and determination to always find the culprit and effectively delegate fixing the build
• Is slightly squint-eyed and can observe build status screens while coding a story/delivering B.V.
• Knows best ways to quickly find out who broke the build
• Knows tools, environments and other people who may help in fixing the build
• Is vigilant, ruthless and unstoppable in making it green
• Sees only two colors: green and red (yeah, the weirdest daltonist ever)
• Understands deeply why green is better how much does it cost when it’s red
• Evolves with the build, learns typical/known issues, gets even more helpful when it comes to fixing or helping others
• Despite additional duties still delivers more story points than others… He is just so freaking good

Big projects full of bright people tend to naturally bring up their very own build whips. Sometimes the role is assigned by management and that’s not particularly good sign because:

• nobody stood out from the crowd to became The One? No inspired devs with above predispositions?
• volunteer may be gently speaking 8-( with the role. If you see him sticking pins in voodoo dolls it’s time to rotate him.

In my short life I met two guys I consider living gods of unholy build whip role. Respect to Igor and Dan.

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.