Archive for April, 2008

The honest EULA

Tuesday, April 15th, 2008

If a EULA actually said what it meant:

This agreement is a legal contract that you (the USER) make to us (the VENDOR) concerning the product (the SOFTWARE).

The SOFTWARE that the USER is about to tolerate is a train wreck in progress. It is difficult to use. It is impossible to configure. It won’t behave as the USER any other rational human being would expect.

In short, it is no different than any other SOFTWARE the USER has ever installed.

The USER will not blame the VENDOR for the behavior of the SOFTWARE, even if the VENDOR would be found criminally negligent or deliberately maniacal. Rather, the USER agrees either to purchase additional SOFTWARE (the UPGRADE) from the VENDOR, or to abandon his data and admit his own foolishness in purchasing the SOFTWARE in the first place.

The USER grants the VENDOR an unlimited license to all information voluntarily entered into the SOFTWARE. If the USER wanted to keep something from the VENDOR, why would he be entering it into the SOFTWARE in the first place? What exactly does the USER have to hide, anyway?

The USER permits the SOFTWARE to contact the VENDOR periodically to transmit data collected about the USER. The USER will not inquire as to the content of the transmission. The USER will not interfere with the transmission. The USER will like it.

The USER agrees to allow the SOFTWARE to install additional products from third parties (the TOOLBAR). The USER will not expect a share of the compensation that the VENDOR collects from the maker of the TOOLBAR. The USER automatically agrees to any EULA attached to the TOOLBAR.

By reading this EULA the USER has already agreed to the terms herein. By ignoring this EULA, the USER is demonstrating his own ignorance and nevertheless agreeing to the terms herein.

Update Controls on Code Project

Friday, April 11th, 2008

I wrote a short article for The Code Project called A Simple Alternative to Windows Forms Data Binding. It's a real quick introduction to Update Controls. The goal here is just to get people trying it out to see how it simplifies Windows UI programming.

It's only been up for a day, but already I've gotten a comment from Marc Clifton himself! If you have spent any time on Code Project, you've read at least one of his articles. The man is a brilliant communicator. And he wears a nice hat.

Please check out the article. And if you haven't done so yet, check out Update Controls .NET.

Relativity and the partial order of facts

Tuesday, April 1st, 2008

Regarding the automotive wireless system that I am currently working on, we are having a discussion about feed reconciliation. It breaks down into two camps: validate everything and reject out-of-order feeds, or accept everything and sort it out later.

In this system, the manufacturer of the wireless device identifies the unit by MEID. They obtain some phone numbers (MDN and MIN) and pair them to the device. They then ship the device to the automaker, who installs it in a vehicle (identified by VIN). Once we have MEID, MDN, MIN, and VIN, we can create an account.

This scenario can be represented with an Entity Fact Diagram. My understanding of the system has changed since this original post, so the diagram is different. A subset of the new diagram follows:

Entity Fact DiagramEntity Fact DiagramWe receive a feed for the pairing of MDN/MIN with MEID. We then receive a feed for the shipment. Finally, we receive a feed from the automaker for the installation of the MEID in a VIN. The installation feed does not include the phone numbers, so we have to have both Pairing and Installation before we create an account.

The argument is what to do when we've received an Installation record for an MEID that we haven't seen in the Pairing feed. It shouldn't happen, because it takes days for the device to be shipped, received, and installed. Nevertheless, it could happen and probably will.

So the validate everything camp wants to reject Installation records for which Shipment has not been received, and Shipment for which Pairing has not been received. Getting things out of order is indicative of a problem in the overall business process, and should be flagged as early as possible.

Meanwhile, the accept everything camp wants to gather and store all of this input, then run reports to reveal problems. Aging reports will show when things move forward too slowly, and exception reports will show when things skip steps. You still get the feedback, but it stays a business problem and doesn't become a system problem.

Here's my solution
The entity fact diagram shows me a hybrid solution. As illustrated, the Pairing feed is a prerequisite of the Shipment feed. The arrow between them has two consequences: first, the Shipment has to have enough information to identify the Pairing. Second, the Shipment cannot exist without the Pairing. This second consequence is of particular importance.

The Pairing and Shipment feeds are from the same source, as indicated by color. These are completely automated feeds produced by a database at the wireless device factory. If we see a Shipment without a Pairing, then it truly is a system problem.

The Installation feed, however, comes from a different source. We have to be more lenient with the relative timing between different sources. If, for example, we are on Einstein's train moving near the speed of light away from the manufacturer toward the automaker, we will see the Installation lightning strike in front of us before the Pairing strikes behind us. Sure, it seems crazy, but in enterprise software these things happen.