Friday, January 30, 2009

It's the Length Of The Compile/Debug Cycle, Stupid (with apologies to Bill Clinton)

More than anything, I blog this to remind myself of this, because I seem to forget it more often than I should:

"The single most important factor in the quality of an individual's software development is the length of the compile/debug cycle"

I don't know how many times I think to myself 'I could set up a proper environment in which to develop and test this change, but it's such a little thing I'll just fudge it'. Like I use the Ant build instead of the IDE build. Or I redeploy the EAR instead of setting up hot class replacement.

And every single time the 'little thing' requires far more compile/debug cycles than I expected, so the job either:
  • takes way longer than it should
  • gets done sloppily because you can't stomach umpteen more compile/debug cycles to tweak every last little pixel alignment

And every single time I wish I'd spent that little bit of extra time, upfront, to set up my environment efficiently.

This principle extends to the build/upload cycle too. If I can reduce the amount of stuff I have to re-upload to the server when I make a change, I can reduce the amount of time I have to get distracted and go surf slashdot, thereby 'context switching' my brain and slowing me down even more.

Anything that reduces that compile/debug cycle is gold. We've all known this for a long time, but I think we all often forget it again too.



Anonymous said...

Do you know ? Try it and save that time

Martin said...

hi Kennard. I'm writing my Bachelor Thesis about how to reduce the compile-debug-deploy Cycle and increase productivity. Do you have any further information about this?

Just to let you know that there is some research going on ;)

Richard said...

Hi Martin,

Sounds like a very relevant thesis!

In my case the issue is less about lack of tools to reduce the compile-debug-deploy lifecycle, more that these tools take too long to set up.

For example, when I'm up and running working hard on a project, I have my code autocompiling and my WARs deploying in-place (ie. without a redeploy) and my compile-debug-deploy lifecycle is very short and I'm very productive.

But when I'm working on something else, and I haven't touched that WAR for a couple months, and suddenly somebody asks for a quick change, the temptation is to directly edit the WAR (outside of all my tools and the productivity goodness they provide) and do the fix 'quick and dirty'.

This almost always backfires. I would have been better off taking the time to set up my tools properly before attempting the change. But setting up the tools can take a significant amount of time. Perhaps if this time could be reduced, the temptation to not use the tools would go away.



Martin said...

hi Richard,
what do you mean by 'set up my tools properly'?

In my project we have the Eclipse IDE zipped and the source in svn. So when you start to rework on a certain project you do a svn Checkout/update. If the IDE was updated I update by using the new zip File.

Maybe the Eclipse Buckminster Project is interesting for you/youre organisation depending how many developer working on the Project

Richard said...


I guess it depends on your particular architecture. For me, things I typically need to do to switch are:

1. Open the EAR+EJB+WAR+test+shared core projects
2. Run an Ant clean on my shared core project
3. Run a full Eclipse rebuild on my EAR+EJB+WAR+test
4. Redeploy MyEclipse 'sync-on-demand'
5. Rerun my shared core Ant script
6. Drop my local DB
7. Pull UAT data down onto my local DB
8. Start my app server
9. Make the change
10. Test it locally
11. Tweak it locally
12. Deploy it to UAT
13. Test it on UAT

Assuming the change is something like an XSLT stylesheet or an XML config file, it can be very tempting to just do it directly on UAT. Of course tweaking on UAT is slower, but you only expect to need a couple of tweaks to get it perfect.

What invariably happens is you need to do a dozen tweaks before you're happy with it. About halfway through that, you start thinking you should have taken the time to pull it all down locally :)

Martin said...

Richard what does UAT stand for? (User accaptance test?) thats also a big temptation for our developers to test on integration level.

Big step towards reducing the Length Of The Compile/Debug Cycle is to not be dependend on it.

How? Write Unittest whereever possible and resonable

Why does this not happen? Mainly because of:

Lack of time

Lack of detailed knowledge how to test complex code

Fear of braking other code while refactoring to make your own code testable

Richard said...

Yes, UAT is User Acceptance Test. But Integration Test has the same issue.

I do not see how unit tests change the length of the compile/debug cycle or address this problem in general.

The problem is the time it takes to re-set up your environment is a deterrant to doing it. You still have to re-set up your environment in order to write the unit tests (and I do write lots of unit tests, and black-box tests).

By the way, are you near the end of your thesis or something? Because your responses are much more directive than information-gathering :)



Martin said...

hi Richard, yes now I have one more week for finishing the thesis.
Could give you a summary after.
Greetings Martin

Richard said...

Thanks Martin,

I'd be interested to take a look at that.