"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.
Gah!
9 comments:
Do you know http://www.zeroturnaround.com/javarebel/ ? Try it and save that time
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 ;)
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.
Regards,
Richard
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 http://wiki.eclipse.org/Introduction_to_Buckminster#Publish_your_Eclipse_project depending how many developer working on the Project
Martin,
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 :)
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
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 :)
Regards,
Richard.
hi Richard, yes now I have one more week for finishing the thesis.
Could give you a summary after.
Greetings Martin
Thanks Martin,
I'd be interested to take a look at that.
Richard.
Post a Comment