Of course!

plaes, you're absolutely right. Let's see how quickly I can correct that title ...

Further reading

Here is a useful bibliography for working programmers ready to take on the multi-core monster.

Debug design? Requirements?

Yes and no. No, there aren't executable debuggers for the overwhelming majority of "requirements" and "designs". Yes, though, there's a vast literature on techniques to formalize and automate analysis and design.

Thanks for raising the question. I'll make a point of covering it in more detail in November 2009. For now, I'll simply offer the tip that the smartest single thing I know to do is to bring in testers and documenters as early in a development cycle as possible. Applications that can't be verified or explained ... well, that stacks the odds against success.

Mac OS built-ins

While I assume Naked Bunny already realizes this, I'll document it for others who might be reading the thread: Mac OS has built in a thoroughly usable RDP client for at least four years. In my office right now are three open laptops. The Mac is the oldest. It's the one I use for RDP.

I entirely agree that large swathes of computing life amount to use of terminals or slightly-glorified variants.

Dirt detection

Right: I know of no formal approach that can reasonably guarantee correctness. What we do have, though, are good probabilistic models that allow estimation of, for instance, mean-time-to-next-detection-of-a-fault.

So what do we do in the meantime? I like to start with what's already at hand; an example is the analysis that supported construction of an existing schema. I take those things seriously; if one says that each customer has a single customer ID, I write executable code to confirm the same. I've written about a few of the SQL expressions that I find useful.

I entirely agree with putting such results in front of users. In different organizations, I schedule daily or weekly anomaly reports to be e-mailed to managers, and/or provide Web pages that report on "live" data. While cleaning out anomalies doesn't make all data correct, it can be extremely instructive to trace back to the root causes of errors; the effort that goes into correction of such trivialities as spelling errors or inconsistent capitalization tends to turn up deeper issues.

I look for anomalies of all kinds. If we have a dozen different groups where users have chosen a few thousand instances each, but one group with only five members, I suspect a problem. If string data with the high bit set starts to show up in a table of user-readable content, I investigate.

There aren't technical solutions in this area, but there certainly are technical tools, ones that, in the hands of an experienced practitioner, can help reduce the incidence of errors by orders of magnitude.