Knowing .NET

I was thinking about buying the videogame “Star Wars: Empire at War” (not that I have any spare time). Anyway, I decided against it because I was sure, like most games, I’d abandon it after a few hours. And I realized that one reason I do that is because, unlike thrilling movies (like “Star Wars”) or books, videogames very rarely make things worse and worse before handing you a great triumph. Generally, videogames go like this: Prologue: Trains you. Act I: Simple levels acquaint you with the games capabilities. Act II: Bigger levels, with more enemies. Act III: Tons of enemies. And then you’re done. But it’s essentially the same damn thing over and over. Even the ones that change, because of technology trees and so forth, the gameplay doesn’t change much. You have Mark V lasers instead of Mark I lasers. Your units move faster. But it’s still building up a stack of chips and measuring them up against the computers. It’s not like a thrilling narrative, where the protagonists loose for a long time, slowly learning new things, and then everything comes together in a pitched battle (which the good guys win).

I have a high-deductible PPO medical plan: if I go to a Doctor, I pay the bill directly. It’s not unusual for there to be a discount “If you pay at the time of services.” Generally, it’s around 25%, but sometimes it goes as high as 50%. I interpret this to mean that the work and “insurance adjustment” associated with processing an insurance claim works out about the same. And it makes sense to me that insurance companies pay a little less than the Doctor’s “walk in” charge in exchange for access to patients and the assurance that, even if the amount is lower, the HMO is going to cut the check at the end of the month.

Tina, on the other hand, is in an HMO. We just received one of those “This is not a bill” statements of insurance behavior. Tina’s surgery was billed by the doctor as X. The insurance adjustment was -78%! I’m baffled. The premium (as it were) being paid by the surgeon to participate in the HMO is incredibly out of whack with the “walk in” rate. I feel that there must be an economic reason for the surgeon to keep their nominal rate out of whack with their expectation.

Now, it may be that the Doctor knows that they can charge X to a walk-in and that the more specialized the Doctor, the greater the disparity between X and the insurance payment. But just from a bookkeeping standpoint, I would think the Doctor would attempt to bill the insurance company something in the realm of what is expected (more than what is expected, to pressure the company to raise its payments, sure — but not 4x the expected payment!).

I wonder if they can write off on their taxes the insurance adjustment.

Alan Zeichick, in today’s SD Times News on Thursday, observes two aspects of Borland’s re-org that are troubling: “The first is combining sales and professional services together into one field operations group. The other is folding customer support into research & development.”

Zeichick says: “Knowing that the goal of a sales department is to increase revenue and meet quotas, do you think that Borland’s professional services?ahem, now field operations?team is going to be looking for ways to offer you advice on how to save money, or on how to spend more money with Borland? I can see why Borland thinks it’s a good idea to turn consultants into salespeople, but I don’t think it’s good for customers.”

He’s less troubled about the customer service / R&D combination, but it seems to me equally troublesome. They are vastly different services, one focused on what’s shipped and one focused on what’s (at least) one release away. R&D requires a mindset that, to a certain extent, waves its hands (“if every developer had dual monitors running at 1600 x 1200, you could have an environment that looked like this”). Customer service requires a mindset that is all about the specifics (“they’re running at 800 x 600 and they don’t have accelerated graphics. How do they make the project window visibile?”).

It’s hard for me to imagine a combined environment providing the focus that both vital services require.

Marco Cantu (hi, Marco!) notes my posts on Delphi and makes some very well-taken points, notably:

• Delphi’s “class helpers” are equivalent (or at least similar) to C# 3.0′s “extension methods,” so Delphi itself could be used as an example of my “trend away from structural explicitness”;
• There’s nothing inherent in Delphi preventing it from evolving towards a language that embraces a more flexible structure;
• What’s with this emphasis on C-style syntax, when half of Larry’s examples are about Ruby?

The “C-style syntax” thing comes from the simple observation that Java and C# are two languages that have come onto the scene and, more than other languages in the past decade, have clearly ”achieved orbit”: although it’s hard to separate them from their libraries and environments and corporate promotion, I don’t believe that millions of programmers were “duped” or “ignorantly stumbled” into learning those languages. I just make the observation that the market has voted several times for languages that use curly brackets and semicolons.

I’ve speculated that perhaps a language with a C-style syntax and LISP- and Smalltalk- influenced semantics might be The Next Big Thing. In that same post, I also said that another possibility is a “collapse” towards a more simple syntax (I did a fair amount of Lisp programming this Winter and Spring and found myself liking the parentheses). And, just to cover the bases, I also said that C++ showed that a hybrid syntax, even if complex, may be embraced as a ”bridge” between two different eras.

Microsoft was granted patent 7,039,699 today, which on reading the claims appears to be: use a GUID as a database ID, send it back as a cookie, and share usage data between computers within the domain with access to the central database. The entire claim (that’s the important part) is obvious “to one of ordinary skill in the art.” The only things conceivably unique about this are:

1. the choice of a GUID as a database ID, and
2. the limiting of database sharing to machines within a single domain, and
3. the use of Web bugs to break out of the domain

1 is not just a well-known practice, it was discussed in print (in Software Development, if nowhere else) prior to 2000. The second — limiting access of a database to a sub-network — is so absurdly trivial that it may not appear in previous patents. The 3rd was done, by the company I worked for, in 1999 (at least 5 months before the time the patent was orginally submitted) and when I considered patenting it (yes, I considered patenting the Web bug: sorry.) I discovered it was already a somewhat-known practice within the Web development community.

Bad patent.