On re-use

Here's a situation for you. You have an information system that runs a substantial internet-based service. That service has web-based interfaces to it for billing and self-service purposes. Now, imagine, that there is a need to branch out, to build the services into different channels. For example, have one application that can fit into the client, one that works on regular browsers, one that is targeted with people with bad eyesight and one that works on handheld devices.

So the question is: how mych of the original web offering can you re-use? It is obvious, that all of the business logic like billing, core provisioning and customer management services need to be re-used, that's a no-brainer. But what about the application and presentation layers? The presentation layer is also quite trivial as the various new versions are meant for different devices and audiences they clearly need a different way to manifest themselves.

The application logic is the one that will cause you trouble. Let's stop pretending that we are talking about a random company here and admit that this is Skype. For example, the purchase flow of purchasing a SkypeIn number, is a very complex beast with tailored integration points for different countries, various ways to pick out the numbers etc. So how would one re-use that?

One way to do it was to use the same application logic everywhere and just re-skin it into WAP or slightly more compact HTML for various distribution channels. This, however, does not work, because different devices tend to have different requirements towards the page flow (which is a manifestation of the application logic), too. For WAP for example, you probably want to generate most of the pages into a deck from one requrest so you don't have to go back to the server every time user clicks "next". For the client-based version you probably want to ignore several corner cases and make the flow a couple of pages shorter. And so forth.

The other would be to re-write the whole thing and build a semi-intelligent fourth tier in place that can handle the workflow, decide when and how to talk to integration partners, give out number pools etc. This would work, but it adds additional layer of complexity, the existing stuff has to be re-written (re-writing something for technical reasons is always a bad idea) and there is no guarantee that this thing would actually contain any useful logic after you are done. Close, but no cigar.

Instead of these options, I'd say just take a deep breath and do not re-use. Lot's of people will not go "no, no, no! You will get yourself into a world of pain every time a common piece of logic changes as you need to go and make a change in all of those flows and you will surely forget something". In my mind, it is much worse to make a major business logic change without explicitly going over all the places that use it. And if you are already doing that, you might as well implement the change right there. Application logic is a combination of delivery channel requirements and business logic so any change to the latter is going to have an impact on the application logic that is specific to the channel. Meaning, that you would most probably go and tweak all the flows anyway. And if you forget any, you will be in trouble either way.

In summary: do not break your head about re-use. In case of the application logic, you sometimes need to gather your courage and not re-use at all.

Metaphor: drawing a horse

I found myself amid of a major discussion the other day. When defining the scope of a project, should one also state things that are _out_ of the scope? Some people said that this would lead to wishful thinking and describing the whole world in the "out of scope" section. The others said that everything _in_ scope could never be described in adequate detail anyway so describing the outer world is the only way to go. So I got into thinking (considering I also had to present on the issue), ended up with an analogy:

Say you wanted to draw a horse and did something like this (art lovers, look away now):
It ain't pretty, isn't it? One could also use a different approach:

Isn't going to win any prizes also. But combine the two:

And you get something that is still ugly but at least gives a sort of holistic view of the animal. So the point is that you need both the inside-out and outside-in perspectives on a project to get a sufficient understanding of its scope.