We have all heard the term Just-in-Time as it related to Java (or maybe you hear it in relation to an earlier language - was Java the first to feature a JIT compiler?). It means that the last step of compilation is done in near-real-time, moments before it is needed. This was intended to let Java be truly cross-platform, running the same program on any machine that had a JIT compiler. Sounds powerful, right?
Well, it is a bad example to start with, because Java’s cross-platform efforts never quite delivered on the promise. Or, maybe they did but it took many, many years before they did - Eclipse is a pretty compelling example of an application that is written once (sort of), and runs on many different platforms. But even Eclipse has its problems - speed, optimization, etc. Nonetheless, JIT compiling has gone on to become a big part of modern programming - .Net uses the same trick, as do all interpreted languages, and the combined success of Python, Ruby, and the .Net languages is clear.
So doing something at the last possible time allowable turned out to be a powerful concept in computing languages. Would it be a powerful concept when it comes to say, doing your laundry? Maybe not, though I think we all do it. Doing your taxes? Again, I think we have all experimented with JIT taxes, and no one would necessarily say it is a great idea.
JIT in Other RolesIt turns out there are other examples of when waiting to the last minute makes a lot of sense. Take for example, its advocacy in Agile methodologies, where the value of waiting to the last possible minute to make a decision has been explored. For a lot of us, our instinct is to try and set as many “hard and fast” decisions up front as we can, it just appeals to our logical brains - we have firm boundaries to work against as we start a project. But all of us have been involved in projects where the best business decision is obsolete long before the end of a project, and work gets thrown out. Agile is not designed to prevent work being thrown out, but if you could have delayed that decision, the one that caused you to build something that was later not needed, you might have done less work that needs to change now. You might also have far more data to make the decision with. You might even decide the decision is no longer important. Lean manufacturing advocates this too - don’t do work that isn’t explicitly necessary yet, wait till you really need to do that work.
So JIT is powerful in areas other than pure programming languages. Where else might it be powerful?
JIT in UIWhat about in user interface design? we have this tradition in UI design to stack up “preferences” into a reasonable buried panel - often at least at the bottom of a menu, sometimes at the bottom of a 2nd tier menu. Then, the preferences screen has several tabs, dialogs, and drop-downs that further obscure those settings. Why? Because you only need to set that setting once, right? Then never, ever again, as long as you use the program.
But that is not really true, as we have all experienced at least once. Take for example a setting in iTunes, that controls the gap between tracks when burning a CD. For most CDs, the default of 2 seconds is appropriate. But, for a CD where the tracks are seamlessly connected, it is not. Now, you are thinking, this is not an example of a bad choice in iTunes to make this a preference when it is not, but rather a missing feature, for iTunes to understand the difference between the two types of discs (which it finally now does), and to burn the disc appropriately based on this data (which it still doesn’t do, but hopefully will soon). And that’s true. But, because you could always set this setting, and burn a disc with no track gaps, it could have always been presented at the moment you are burning the disc (or maybe, building the playlist), and not in a hidden preferences dialog. Asking the user at the time they are working with a unique disc, or right before they burn the disc, is more appropriate than asking the user once when they are setting their preferences.
So if you find yourself building a UI and placing a lot of preferences in a single, Preferences dialog, ask yourself if it is not more appropriate to ask the user another time - at the time they are actually doing the action that this preference will effect. If asking seems like it might get annoying, there is always the option of using the Always use this settings checkbox with the question. But, you might find that asking the user each time is very appropriate since the answer will change.
Where else does your UI assume an answer, or try to gather information early on that the user may not be prepared to give? Might it not be better to gather that information just-in-time?