Red Flags: Spot 'em early...

I'm a firm believer in theory, as in meta-knowledge that lets you intuitively jump ahead over hours of logic. Intuitively? Well, it's probably because I lack intuition that I have become a fan of laboriously building theory as a structured replacement!

In this spirit, I offer you a few "red flag" indicator phrases...

Why would you want to do that?

The person who says this just does not "get" it. Rewind your argument to try once more to show why TSM ("this stuff matters") and if no joy, consider this person an unmovable rock you will have to flow around. Example:

"Autorunning macros in data files is powerful stuff - but what if someone were to write a macro that overwrote all the files in your root directory?"

' Why would you want to do that? '

People must...

If you hear this in what would otherwise be an enlightened political discussion, then beware; here come the stormtroopers!

"But what if folks don't want to work for the common good?"

' Well, the people must just do the right thing, I mean if ... '

And another thing!

If you catch yourself saying this in the course of an intra-relationship negotiation, you might just possibly be a nag - and a depressed one, at that. If every spark brings out a litany of unrelated complaints, then chances are there's some deeper structural problem that's locking you into a state of conflict and resentment. Do whatever you can to improve your position; the chances are that in so doing, your efforts will benefit more than just yourself.

I spotted myself saying this within my relationship with Microsoft, and am following my own advice!

We can't not install that, because...

"...our system design is bad", is the usual reason. Why would anyone want to not install something? ("Why would you want to do that?") Most likely because there's a risk to it, or some other cost (resources, maintenance committment, price tag) involved.

When the response is "we can't not install that" for some technical reason, then this implies the wrong code has been generalized across the wrong scopes, i.e. that your damage-control bulkheads are in the wrong place. This can be such a deeply-rooted problem you may be reluctant to re-engineer it, but trust me; it's going to hurt, and keep on hurting, until the need to maintain backward compatibility with this design has finally gone away.

Windows XP abounds with examples; Remote Procedure Call, hidden admin shares, the pervasiveness of HTMLwithin the OS, even the consequences of the Win95 decision to flaunt the new Long File Names feature when naming "Program Files". One of the big lessons of XP Service Pack 2 was how painful it is to rewind dangerous functionality later.

Do I really need to flesh this out? OK, one example; Remote Procedure Call. This exposes code to direct Internet access, and this code is non-trivial enough to be exploitable (Lovesan et al). Microsoft tells us that "if a bad guy can run code on your computer, it's not your computer anymore". By design, RPC facilitates this; by code defect, all the more so.

XP is NT, NT was designed as a network OS, and it treats the Internet as just another network. Because it's so tempting to flatten natural hard scopes (see previous blog entry), certain things such as RPC are rolled out to work seamlessly across networks, as if the local PC and network were all one system (as if they'd been smoking Sun's giggle weed).

So now you have a face-hugger dependency; you can't amputate RPC because the local system relies on it to manage itself. See the problem?