Dead Time (...code, compile, wait, wait, wait, test, repeat)

by Tim O'Brien

Most programmers develop in cycles. Code, Compile, Test, Repeat. Depending on your process, you might add stages like Test, Code, Compile, Document, Deploy, Verify, Commit, but, as a rule of thumb, the programs of highest quality are usually those that are not a chore to develop. The ability to execute code immediately creates an efficient feedback mechanism that increases quality. If your cycle is quick, you'll be able to debug and correct bugs faster than if you are constantly having to wait minutes to see if your current set of changes works. A long development cycle is similar to the experience one has trying to use a command line editor over a 300 baud modem - the time lag between typing and reading what you've typed causes speed and quality issues.

Ruby, Perl, Python...scripting languages are technologies with very quick development cycles. In a scripting language, you can make a change to your code and run it immediately. Compiled languages such as C, C#, and Java have slightly slower development cycles because they require compilation, but if you make the right choices you can attain a quick development cycle in Java. For example, the Sysdeo Tomcat plugin uses a custom classloader that allows you to modify your servlet code on the fly without having to restart your servlet container, and there are various approaches to speeding up Java development cycles using swappable ClassLoaders and the like. But, don't let anyone tell you that a speedy development cycle is impossible with Java, it is possible, but usually not the norm.

There are times when one bad product selection or one misconfigured framework can ruin everything by introducing a huge span of dead time into your development cycle. Read more for a discussion of Development Cycle "Dead Time", and how it can affect your approach to development.


Ryan Sonnek
2006-03-30 11:06:45
Nice article, and I think many of your points are valid. One thing you might want to consider in this whole "dead time" concept is "execution speed". Compiled languages *are* faster at execution time. It may not be significant, but that's one of the main reasons that compiled languages are still around.
Tim O'Brien
2006-03-30 14:21:39
re: Ryan S.

No doubt. I'm not discounting compiled languages. the tradeoff between something like Ruby vs. Java is that Java's performance is going to be better in a production environment. What I'm trying to say is that regardless of the performance goals in an organization, minimizing startup costs for a product are going to benefit the development cycle.

I've worked in many situations where a company's "application" is a very complex web application that takes minutes to initialize. In general, I think it advantageous to be able to hot deploy code to a working application without having to pay the cost of restarting the [jvm|container|cms|ejb server]. It is something I think people need to approach - speed for the user is important, but speed for the developers is just as important to productivity.

don't worry, this isn't a ruby is better than java piece. ;-)

Alex Vollmer
2006-03-30 16:55:01
Tim, I think you are dead-on here. Build systems aren't very sexy to work on, but they usually need more care and feeding than just about any part of a system.

I'm always amazed how quickly people can let it get out of control and start consuming the dev cycle. I think the two main "smells" of build systems getting out of control are long build times and fragility. Both need to be addressed as soon as they appear.Here at work we call those the "productivity governors".

I can't stress how important it is to aggressively refactor your build as much as you refactor your code. It's not terribly fun but if you don't you will incur an insurmountable debt. Thanks for the article.


Tim O'Brien
2006-03-30 23:23:16
Alex, thanks for the comments. Two things stuck out, the idea of a long build time being some kind of "productivity governor" - this is exactly the point. When your build or product takes minutes, you limit productivity. For anyone not familiar with the use of the word governor here, Alex isn't refer to "governor" as an elected official, he's refer to governor as a "feedback device on a machine or engine that is used to provide automatic control, as of speed, pressure, or temperature". A governor is usually used in an automobile as a feedback mechanism to create a maximum speed.

Also, "Insurmountable Debt" is a great way to put it. In my example, the legacy application I'm trying to improve takes approximately 8 minutes to initialize (most of that is hibernate). This is a price I have to pay everything I need to restart and test. losing 8 minutes 10 times a day adds up to a lost of lost opportunity/money.

Glenn J. Mason
2006-03-31 03:09:59
I completely agree with what you've written here, and wasted far too much time on projects for exactly the reasons given. There are some nice ideas around -- management interfaces/APIs which could allow portions of code to be replaced for quick testing without restarting an entire infrastructure -- but more often than not (in my experience) they are not used effectively, or not available on the target platform. Java has a great, and greatly under-utilised, feature in it's reflection API I think.
Maarten Meijer
2006-03-31 12:27:54
Good piece. I had a simple web application starting to suffer from that. I thouroughly refactored the testing code: all beans without deploy locally, then after deployment only integration tests, then when that worked tests on remote server. Also in designing, I now make sure that functionality is testable standalone.
Big picture: in the US/Europe long cyles translates to high cost, thats the drive to go to India. There you can get the same 'development power' for less or increase by putting more 'cylinders' in your development 'engine' But your story rightly points out that development is also about individual tasks that needs to be done in a single 'cylinder' because of human brain and concentration constraints. Each cylinder must make a minimum number of revolutions to be efficient, so the cycle time must come down.
That is the single most important factor in selecting frameworks and tools: does it allow optimal cycle time? That beats reusability or architectural neatness every time.
2006-04-02 22:11:35
Food for thought .
Christian Gruenberg
2006-04-03 03:20:20
Very interesting! In addition the development environment (which is almost your own pc) has a deficit to the productiv environment. So the response of a development enviroment is partly very slow.
This are only some seconds per cycle, but for the whole project it can be more than a day.
Asif Iqbal
2006-04-04 20:31:33
Well written article. This is a problem we face everyday.