Monday, November 29, 2004

Designing generic systems/functions

 Originally posted on:

This is a constant issue here at the company, and I guess that it arises almost everywhere.

Let me first explain that we are a company that deals with software development, and mainly for our single product (which is in fact several, but it doesn't really matter).

Each time we develop a new feature, or update a previous one we are of course forced to deal with issues of backward compatibility, and others not only within our products but also with various third-party providers that integrate into our system. This is a known problem for everyone including even (and especially) large companies like Microsoft. Each deals with it in it's own fashion, from introducing a completely new set of APIs (.NET) or just adding new ones where there is no option within the existing API framework.

But I'm not here to discuss that, the problem I want to write about is quite different.

One of the concepts every programmer has heard about (even if some do not implement it) is code re-use. Writing good functions/objects/routines/components (or any other name you want to call them) so that in the future you can take that component by itself and use it to save time, money, and duplicate code. This is a challenge in its own way, and achieving such a level where you can create a project from neatly stacked components is very hard to reach. But the benefits to this approach are quite easy to see - especially in software companies. And this is why of course, managers in software companies push their programmers to achieve this.

This in itself of course is no problem, however, in most cases, there are additional requirements that filter down with each new version/feature that require different output/ more data/ less data etc... Question is, with all the good intention, how to design a component that will forever do whatever is required from it?

For example, we have a standard error format for our web services, and it is based on the internal error format which has been used for years. It is no problem for me to push in almost any data into that internal error object, however, the Output format for the web service is a simple (yet efficient) Code/Description model, where the user gets an error code, and with it a detailed description (that when relevant contains the specific problem in the field).

All of our web services, are managed through generic code, which parses the incoming data, validates it according to the business rules etc. The errors are converted from the internal error object, by another generic function that knows to convert the internal error object to the readable form.

Suddenly today, comes someone from the management and demands this special API (with which I can't argue, since it IS needed). However, because of special issues (it is a special API) some of its features including the input format and the error output are quite different than those of all the others. All generics are broken! this function need eventually to have some code duplications (since we don't want to hurt the behavior of the other APIs) and specific modifications for it.... This is driving me nuts.

Does anyone have a solution, or is this why we still have work (as programmers)?

Just venting here, I'm not REALLY angry....

No comments: