Unplugging
Stephen Tilkov pointed at Paul Ford's latest, where he says
I don't want more information, more feeds, more sources. When I write, when I think, the Internet is just too much for me to fathom. It's a wonderful tool for research, a good way to kill a few hours. I grew up with computers, started hacking away when I was twelve. I always thought that the Internet would make me more productive, more aware of the world around me but instead I'm using technology that was laughable in 1995 and getting much more done.
Paul gets a little silly to make his point, but there's a truth here. There was a coffee shop around the corner from my old house, and it was a great place. They roasted their own beans, had lots of comfortable funky chairs and good tables, and had no WiFi connectivity whatsoever. on the odd occasion that I went there with the laptop, I was always at my most productive, because there were no distractions. I'm also one to succumb to the temptation of loading up with information, rationalizing that I need to gather information, when I know that quietness is most condusive to work. Paul's essay reminds me of another that's been rattling through my head lately:
We have the Saint Vitus' dance, and cannot possibly keep our heads still. If I should only give a few pulls at the parish bell-rope, as for a fire, that is, without setting the bell, there is hardly a man on his farm in the outskirts of Concord, notwithstanding that press of engagements which was his excuse so many times this morning, nor a boy, nor a woman, I might almost say, but would forsake all and follow that sound, not mainly to save property from the flames, but, if we will confess the truth, much more to see it burn, since burn it must, and we, be it known, did not set it on fire — or to see it put out, and have a hand in it, if that is done as handsomely; yes, even if it were the parish church itself. Hardly a man takes a half-hour's nap after dinner, but when he wakes he holds up his head and asks, "What's the news?" as if the rest of mankind had stood his sentinels. Some give directions to be waked every half-hour, doubtless for no other purpose; and then, to pay for it, they tell what they have dreamed. After a night's sleep the news is as indispensable as the breakfast. "Pray tell me anything new that has happened to a man anywhere on this globe" — and he reads it over his coffee and rolls, that a man has had his eyes gouged out this morning on the Wachito River; never dreaming the while that he lives in the dark unfathomed mammoth cave of this world, and has but the rudiment of an eye himself.
— Gordon Weakliem at permanent link
Simplifying Assumptions
Justin Rudd has a fascinating post that touches on two subjects dear to me: asynchrony and simplification. The first point was brought home to me in a big way: at my previous employer, I ended up writing web service front ends for 1970's-era mainframes. The travel industry is fraught with creaky old systems, and through the Galileo "Links" system (which ultimately boiled down to everything from the Internet to teletypes) our web services were exposed to those creaky old systems. One lesson we learned, painfully, is that when you create a system joined at the hip to a creaky old system, you have created a creaky, new system. After colliding with some of the odd behaviors that ASP.NET and IIS exhibit when faced with thread pool and connection pool exhaustion, we went through great lengths to remove synchronous bottlenecks, an effort that was inhibited by a decision to rewrite the entire system (twice, as it turns out). One of my co-workers argued that the new systems would be faced with the same scaling issues, but was (somewhat voiciferously) ignored by the more learned members of the architecture group. As it happens, we moved on to other endeavors, but my friend has been telling me about a continuation passing style framework he's created for .NET. This amounts to a mechanism where you call methods with a success contituation, a failure continuation, and a timeout continuation, free of worries about thread pool utilization: threads from the pool are not consumed while a method is waiting.
Justin's second point about complexity reminds me of my experience with CORBA and Iona's Orbix implementation. At that job, we collided with a number of scalability problems that remained unsolved when I left that position. I later attended a course given by Douglas C. Schmidt who dissected the problem with Orbix: as a toolkit, it was the ultimate in flexibility. You could build services in any number of ways, but performance-wise, that was the problem. Orbix had to lock everything to ensure thread safety, and the locking costs caused Orbix to perform much worse than other implementations. I've said it before, but it bears repeating: "know nothing" architectures are a really bad thing.