I don’t have time to sharpen the saw, I’m too busy chopping wood!

Title by Steve Donie, my former colleague and sensei for all things related to Continuous Integration and Configuration Management. 

I'm suggesting to my client that they need to invest in some CI infrastructure for the remainder of their code.  They're all in favor, and they want to do it, but it's not a priority because the have "too much sh**" to do.  That's understandable, but it's a self-defeating attitude.  In my client's case, I think a little CI with some smoke tests may be low-hanging fruit.

Granted I've got a lot of CI experience by now, but I really don't think it should take you more than a couple of man days to set up CruiseControl.Net or something similar.  Compare that to the potential loss of time resulting from, for example, a new JAXB mapping gets checked in that breaks a service downstream or database schema changes not getting propagated to all of the development and testing database installations.  How much manpower is lost because of those problems?  Those very problems can be stopped in their tracks by a good CI infrastructure and philosophy (meaning that somebody has to watch the builds and care when they are broken).

Developers aren't omniscient (sorry).  You can minimize the pain through good coding structure, but changing existing code always presents the opportunity to break something else.  That something else might not be detectable from mere code inspection.  It's a good, good thing to have the CI safety net to detect problems automatically. 

Automate anything that moves!  Any code, or configuration, or database change that happens repeatedly with anything resembling regularity should be automated.  When you're tallying up the cost versus benefit of writing Ant/NAnt/Rake scripts, you absolutely must include the cost of productivity due to screwing up manual activities.  When you do that, you might just put a little more value into the build automation. 

Granted, a nightly/daily build beats nothing hands down.  That being said, the great advantage of full blown CI, with the philosophy of checking in code often, is creating a record of causality between a build breaking and the new code that broke it.  Small frequent check in's both lessen the chance of breaking a build by making smaller changes at any one time and ease the burden of diagnosing build or code problems by immediately pointing to the last check in (readily available on the CruiseControl.Net build page).

A lot of the blame has to fall on management's shoulders (and I'm not thinking of anybody in specific here), because they often don't understand or believe the opportunity to go faster by tightening up build or test automation.  I don't know how you get around the "management won't let me do the smart thing" issue.  The best I can say is to do the things that will make you faster when you need them and not even tell management.  As long as you really are making yourself faster, and that's the rub, you should come out ahead.  If things are bad, just buckling down to work harder probably isn't going to help matters.
 

 

 

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Continuous Integration. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://camelCasing.wordpress.com converdb

    Hi there, after a long time dealing with the “management won’t let me do the smart thing” problem I’ve come to a clear and releasing conclusion. Solution is clearly not to tell until you can present some “moneytizable” results, man/days saved, problems avoided, quality kpi, you name it. The reason why is quite simple, this is the only language management talk, that’s their only protocol in the stack.

  • Don

    Maybe your using the wrong tool? Trying to chop wood with a saw, and not an axe, seems self defeating.

    On a similar vein, working with clients who don’t understand the value of CI, and think they will get to it when they are “caught up” is something I’ve seen many times before. I’ve tried showing them charts, reports and studies, but all failed because of NIH.

    What has worked? Brutal honesty with conviction. For example, in my current job I had a meeting with stakeholders. I started out the meeting by having them give me example of “sh*t to do” they had right now. I then asked them to go back three months and think about if the list was any shorter. Six months, a year. Now, how many of their to do lists are less than one month old? How about a week. Now, project forward three months. What is there to do then? What is the likelyhood of new sh*t popping up between now and then? How about six months, a year?

    With this on their minds I made an edict “You will always have too much sh*t to do. Always.”

    Next I asked, how much of their to do list is new stuff and how much is fixing old stuff. It was all new. How much time is spent each day fixing the old stuff though? Significant. How do you avoid fixing old stuff? By fixing it while it’s still new. Duh. How do you find the problems with the new stuff? CI and TDD.

    We spent the next sprint setting up a unit test/builds server. A trigger was set so that when a check in is made, a build kicks off and the tests are run. Any failure causes a rollback and the files to be returned to sender.

    There’s still too much sh*t to do, but at least now it’s (mostly) new stuff and the sprint backlogs are getting longer as we are able to do more.

  • http://vikasnetdev.blogspot.com/ Vikas Kerni

    What if you break the teeth of saw while sharpening ?

  • http://stewartr.blogspot.com Stu

    Hi, Long time lurker, First time poster :)

    I definitely agree with your last comments on management. Do they need to know/approve every detail of your development process?

    It kinda fits a post I made last week.

    http://stewartr.blogspot.com/2006/11/unit-testing-is-dev-task.html

    Keep the good stuff coming.

  • DaRage

    If I had six hours to chop down a tree, I’d spend the first four sharpening the axe.

    Abraham Lincoln (1809-1865)

  • http://devdeacon.blogspot.com Brian Deacon

    Absolutely! Automate anything that moves. If you’re throwing a document over the wall with instructions that say “do this, then do that, then do this other thing”, then you’ve found something that needs to be automated. If a trained monkey could do it, then a human shouldn’t be doing it, because we will always mess it up eventually, and we won’t know how exactly we messed it up this time.

    When you throw a document over a wall, ideally it should be as close to “click here” or “execute this command” as possible.

    Environment-specific settings (dev, qa, production) often throw a monkey wrench into this, but there are still techniques you can use to get you to full automation, and just switch settings based on the environment.

    I think part of the attitude that makes not just management, but devs also, think it’s not worth the time, is that CI and automation protect you from things that “shouldn’t” have happened. And we don’t tend to factor in failure in our planning. This is more obvious in time estimation. The customer doesn’t want to hear, “This would take me 3 weeks if I do it right the first time, but I’m going to need to mess it up a few times first. On average, I mess it up about three times before getting it right. So give me 6 weeks.” Mess ups don’t mean you have to start over.

  • http://codebetter.com/blogs/jeremy.miller jmiller

    Good to hear from you Chad. That’s a much better excuse;)

  • http://www.hdri.net Chad Myers

    I don’t have time to read blog posts, I’m too busy coding!