A while ago, Austin was on FSBreak, and I wrote this post as commentary on his interview. The main point I meant to make was this: from what I have heard from other engineers and seen in my own experience, most software companies prefer to develop new features on top of implementations that are known to have architectural problems. At LR, we fix the implementation architectural problem first, and that has been a net win for us.
Now that's basically a statement of my opinion on software engineering - in hindsight it probably belongs on my programming blog and not here. Unless you develop X-Plane plugins, you're not a programmer; I will try to constrain future scenery blog posts to things that non-programming X-Plane users will notice. If you are a plugin developer, you might want to look at the "Hacks of Life" posts tagged with OpenGL.
Anyway, back to the story...the responses to that blog post were all well thought out comments on X-Plane's quality control process. At the time my immediate reaction was: that's totally off topic - I'm commenting on architecture and they're talking about QA. I do think the authors made fair points.
But in hindsight, I think that there's a deeper issue: one of verifiability. Simply put, my statement that we (LR) rewrite stale implementations is nearly impossible to verify without source code access, something that you can't get for X-Plane. So from the perspective of anyone outside the company, my original statement is not falsifiable (it cannot be proven false) and thus rather useless as a statement of fact. Even though I claim that we make rapid progress on features by keeping implementations clean, you as a user don't care how we develop our features - clean architecture, more developers, or the use of time travel and voodoo dolls, it's a bit moot.
Thus the comments were off topic, but also they were moving away from an unverifiable topic and toward one that users can measure, namely the quality of X-Plane's betas.
There's a fair amount of marketing that gets put out in the tech and games industry. It's a slippery slope from giving a new, real technology a whiz-bang name (e.g. HyperZ is a real technology, and it is good for your frame-rates) to using techno-babble to make the bad seem good (e.g. HyperMemory just means that your video card lacks VRAM and is going to be slow). When new products come out, the feature list is parroted, but it's not always clear whether the new features turn into real benefits.
So what I'm going to try to do with the scenery blog is: try to keep the blog limited to verifiable, measurable aspects of X-Plane. If we ship X-Plane with "psychoactive rendering*", I'll try to explain what the heck that is and why you'd want it, and how you might notice that it's working.
* X-Plane does not have psycho-active rendering, except possibly when I make a mistake in the shaders and everything turns purple.