In college they taught us a concept in systems analysis class about how every phase of a product has a customer. I absorbed that like a dutiful student and tucked in the back recesses of my brain. Fast forward a number of years to the present and I listen to a taping of a presentation on Testing where the notion of a Big C customer and Little C customer is raised. When I heard this I had one of those “Wow! Something I learned in school is actually relevant” moments.

A Big C customer or ‘Customer’ is someone who actually pays for your software. The end client as it were. This could be a separate company, or increasingly is an internal customer as IT is run as a separate business entity within the organization. A Little C customer or just ‘customer’ is the next person/group along the chain. For example, development’s ‘customer’ is test; not Product Management as you might suspect. Product Management is an agent of the ‘Customer’.

So how does this apply to Quality and Testing? By recognizing the difference between the two, you can develop/architect your application to be more testable. How so? Why, I have an example. I was recently talking with some people who were re-architecting how their application is deployed from something like this

+-----+   +------------+    +-----+
| app | - | app server | -  | db |
+-----+   +------------+    +-----+

+-----+   +------------+    +-----+
| app | - | app server | -  | db |
+-----+   +------------+    +-----+

where each app had it’s own app server and database instance to something like this

+-----+
| app | \\
+-----+
+-----+   +------------+    +-----+
| app | - | app server | -  | db |
+-----+   +------------+    +-----+
+-----+
| app | /
+-----+

where there is a number of apps contained in a single app server. Clearly this is a great move in terms of quality as you can start to get economics of testing scale with shared code etc. and having a single platform/environment to worry about.

It is also a cause for concern because they are opening themselves up to cascading failures if there is a bug in the common code residing on the app server. Before the impact would be limited to a single app, but now it has much larger consequences.

Applying the Little C concept to this architectural problem we can say that the apps are Little C customers of the app server. In this case my suggestion to them was have the app server team publish a very strict internal API/interface for the app group to write against. By having this interface clearly defined the app server team could unit test the heck out of it, that way if (when) changes were made to the common code they would know right away if there was going to be a problem in the apps by their continuous execution of the unit tests.

Test would of course enforce the usage of the interface by doing code analysis trickery (via python or one of it’s relatives).

The Big C customer should see no difference of course. All they care about is that their site remains operational. Internally though, the overall Quality of the product should increase as you are not testing the same thing in n places.

The takeaway question from all this is of course: Who are you Little C customers, and what could you do differently to make their life easier?