Oh, crap. Why did I end up reading this blog entry? Now that I'm painfully aware that someone is offering Rails hosting for reasonable prices (I don't consider TextDrive's pricing to be even close to "reasonable"), I'm really tempted to move away from PCHighway (who do have Ruby installed but no Rails, no FCGI, etc.). Then again, I still haven't set up my web identity, so...

Oh, and since I have this Ruby fever going, I decided to create a whole new category in my blog for this stuff so that those who are only subscribing to the Java and General feeds, for example, don't need to listen to me go off about learning to use closures and stuff.

Joel Spolsky (of the Joel on Software fame) has started a series of blog entries shedding light to what they've done at Fog Creek in the past.

In the 3rd installment, Joel tells about how they needed to port their ASP-based application to PHP so that it would run on UNIX boxes as well as Windows. Their solution was to build a custom ASP-to-PHP compiler, relying on a variation of Hungarian notation among other things.

What I don't get is this: If your goal is to make your application portable, for how long is it worth the effort to develop the ASP version and make sure that the custom compiler can keep up with what they're doing? Wouldn't it be easier to go the other way? I.e. compile once from ASP to PHP and then keep on doing PHP only -- deploying on Apache on both Windows and UNIX.

I'm certain that there were valid reasons for sticking with the ASP codebase as the master some 2 years ago but I have to wonder if Joel & Co. should really be looking at switching to a portable language like PHP/Java/Python/Ruby instead of maintaining their own portability layer?

David Anderson blogs about paradigm shifts. I have to say that those five bullet points communicate quite effectively:

• Flow through value chain, focus on throughput and effectiveness - as opposed to, cost and effort estimating and tracking, cost accounting, efficiency and earned value analysis
• Theory of variation (common and special cause) and buffering - as opposed to, deterministic scheduling and Gantt charts and deviation from plan
• Synthesis and systems thinking - as opposed to, Cartesian decomposition, (bottom up rather than top down)
• Process control and continuous improvement - as opposed to, conformance to plan and specification
• Empowerment and service - as opposed to, command and control

Keith Ray is not far from the topic either with his short report of a visit to Toyota's NUMMI facility. Can you imagine working in 83-second iterations? Maybe not, assuming you're in software development. But what if it was 83-second test-code cycles?