October 14, 2010
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?”
– “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:
- Understand what is your work in progress; keep WIP under control; keep it small.
- Develop code in small steps.
- Keep your workspace clean, avoid unknown or modified files between check-ins.
January 19, 2010
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
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.
October 22, 2007
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 =)
September 6, 2007
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:
- 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.
- 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 =).
- 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.