Harder Than You Think
Loading a program into your own memory
Interrupted too much to make progress on your code? I mean real progress, not the kind where you clear a P4/S4 bug by changing some link text or a background color. I mean the kind where to set things right, you have to be willing to take apart large sections of your code, change interfaces and break contracts, make the whole thing uncompilable (you might want to do this in your own local copy and not commit until it compiles again), and rewrite the sloppy stuff that you half-assed the first time, thereby eliminating all the lurking dangers that depend on it. This is the kind of thing where you need hours on end of uninterrupted focus and clarity, so you can keep in mind a vision of what you're trying to accomplish, as well as the details of everything you're having to muck with to get that all right.
OK, seriously, who has that kind of time? Hand me another cosmetic bug, Earl, the engine's gonna have to stay broken.
Paul Graham's latest essay is on the value of Holding a Program in One's Head and it's an interesting read, though you may have to hold your nose every now and then to work through the usual Paul Graham-isms sprinkled throughout (he doesn't bash Java directly this time, though he has a dubious claim that you need to use "succinct languages", such that lines of code are always inversely proportional to language goodness in Graham-land). Anyways, the key to his argument is that you have to fully immerse yourself in a program and a problem domain to really get anywhere with it, and that takes time and focus:
It's not easy to get a program into your head. If you leave a project for a few months, it can take days to really understand it again when you return to it. Even when you're actively working on a program it can take half an hour to load into your head when you start work each day. And that's in the best case.
From this, he infers that office situations are generally antithetical to achieving the necessary focus, given their high level of interruption, seemingly by design. In fact, he asserts that the random interruption may not be as bad as the regular interruption, like the useless meeting coming up at 12:30:
Oddly enough, scheduled distractions may be worse than unscheduled ones. If you know you have a meeting in an hour, you don't even start working on something hard.
Now, here's a thought... do you really think Graham's argument is true in all cases? I was talking with Substance creator and java.net weblogger Kirill Grouchnikov in the java.net booth at JavaOne, and I asked him how it was that he could keep cranking out new releases of Substance all the time, putting in significant new functionality on a regular basis. He said his approach was to always take an hour a day to hack on it. This is counter to Graham, obviously, who says you need a half-hour just to load your program into your own memory. But Kirill's approach has a huge advantage in consistency and familiarity: rather than trying to clear out huge blocks of time to work on your project, the frequent-but-short approach means it'll never go out of your memory, because you'll never go more than 23 hours without working on it.
Deep dives or frequent jams? Which works for you?
In Java Today,
Sailfin, the (SIPServlet) communication application server based on GlassFish and Ericsson's contribution, has hit Milestone 1 (56Mb). This is built on top of GlassFish v2 and offers the following features: Grizzly integration in SIP container, Administration Backend, CLI, deployment, web container, load-balancing proxy. Milestone 2 is expected in October.
Thanks to all who participated in last week's Ask The Experts on Mobile Services Architecture (MSA). Questions and answers for this event are now available to view online. For more information about MSA and other ME-related projects, keep checking the Mobile & Embedded Community page, and the M&E forums for announcements of future Ask The Experts events.
Issue 135 of the JavaTools Community Newsletter is out, with tool news from around the web, an editorial on "why your new project hasn't been approved yet", announcements of new tools that have joined the community, and a Tool Tip on investigating the working copy status using Subversion.