Quiet-time is not down-time; can developer-brain translate into business benefit?

It's been a while since I posted, and although I might claim that my silly season has begun, it's not entirely accurate. As I have alluded to before, I have been making some major technology strides while simplifying my admin tasks (trying to avoid web content like this) and laying the groundwork for other projects. Well, I've come to a stopping point, time for some retro-introspection ...

• If you have any developer background, you can empathize with my urges to rewrite the whole thing (if I knew then what I know now, yada). However, we gotta take the business value out when we can, so it's in production and delivering benefit. Now, before you think me a sellout, check out the comments in this subset; I holdout for engineering nirvana (and future work during "all that free time") by taking copious notes to myself for all those great ideas that I'll get to some day. Sooner or later I will get to them, but it's worthwhile to capture the ideas now, make improvements later.
• Another parallel to "real life"; a huge amount of time spent over the last few weeks on foundational technology, and no tangible, visible results in the site. This is very much like many projects that all corporate IT projects have to deal with - the kind of projects that make articles like this a tad frustrating. No, I don't think the author is incorrect; I do think that there is not enough attention paid to the integrations requirements of applications like Basecamp (project cost accounting or HR interface?) or Salesforce.com (Customer lists and product catalogs?). Of course, I do think that all in IT should find time to play with technologies such as blogs, wikis, ajax, etc.
• I've mentioned these blogs before as well - lots of good coding / developer insights, more hard-core developer than I but still able to make some good business / real world insights. As I dive more into creating neo-classical web apps of my own, with dreams of bigger things, I like to have others point out some Aha's for my benefit ...
• Bosworth (via Horror) has some neat insights about simple / fast protocols / designs, how the web has significantly impacted how people percieve / understand stuff, and how the database universe may be the next to get impacted. The referring post picks off some additional notes on simplicity of design.
• Haack makes some good points about differentiating between available hammers - the lure of Ajax notwithstanding. Also, some good (obvious? maybe, but someone had to point it out) points about the certain level of fragility of web-based apps. Again, something the internal IT groups should be able to understand, and help the business understand - but not to avoid the Salesforce.com's of the world, just to set the expectations accordingly.

I also have to drop in a mention of this post, on another developer-friendly, business-insightful blog, which recalls (for me) a project / request prioritization database built IAPL. We described the problem politely as "can't get 10 pounds of Dirt in a five pound bag ... maybe six if you push real hard, but that's it". Anyway, the database / request list became known as the Dirt Bag, and reports, formal meetings and memos all proudly featuring this name became the norm. We put it together with some quick and dirty tools, made it visible to all using web technology, and got real business value with minimal development effort and expense - not entirely pretty, but elegant, efficient, and useful.

If that's the final summary of any projects / products / applications you work on, consider it a major success.