The Joy of Getting Cardinality Assumptions Wrong ...

(Sorry for the infrequent posts as of late ... just getting back into it. Lots of new fuel to write about. This is just a little note to prime the pump again.)

As a developer, I find that some of the biggest code changes arise when my assumptions of "how many" of something I can expect are wrong.

I thought there would only be 1 when there are going to be N items.
I thought there would be N when there are going to be N² items.
I thought there would be N² when there are going to be 2^N items.
Or, I just guessed N wrong.

Each change in magnitude calls for a radical change in architecture. You have to go from a single variable to data structure, or from a list to a tree or from a tree to a database or from a single database to a partitioned database. Everything changes. Often, the clients of the code break because the access mechanisms change. They don't get back a single item, they get a list. They can't get all the items in a single query, but have to page the results, they have to give better qualified queries, etc.

User Interface is perhaps affected the most by these changes. Going from showing 1 result to N results is a big change. When N gets beyond a manageable number you start thinking about trees ... more UI changes. If N is too large for a tree you start thinking about tagging/search mechanisms. The UI changes again.

Big development costs.

The multi-tenant problem is a good example of getting bitten by these assumptions. You assume you're going to have one customer per installation of your code. But then you evolve into a hosted application so one installation has many customers and no customer can see another customer. Then you support resellers, so a customer is not an end-customer, but a meta-customer than has many sub-customers. The reseller can see all of their clients, but no client can see each other. Ugh. These sorts of changes hurt. They usually take considerable time to implement and it's tough to get right.

So, when you are talking to your customers (or prospective customers), really try to get to get a sense for the cardinality of the things they talk about. Think about how big a change your code will undergo if you had to move from "one of these" to "N of these". Ask them explicitly "How many of these can you foresee?"

Personally I think these sorts of design problems are so painful that I'm willing to violate YAGNI and opt for the larger data structure.