Writing code is not a workaround

As programmers we are regularly faced with the task of creating computer applications, which is a good thing. One of the reasons we are regularly faced with this is that no computer application is exactly like any other - the requirements vary in some detail, the look&feel of an existing application isn't exactly what the user wants, the programmer isn't quite happy with the implementation... On the surface, perhaps from the viewpoint of some manager type person (not a slight - just referring to a particular high level view of things), many applications sound like they are really the same thing.

The task for the programmer is to reach the goal of creating an application that satisfies all the requirements exactly, from a technical point of view as much as with regard to end user functionality. To reach this aim, he (or she - just using the masculine form for simplicity) looks around for reusable components that can be the building blocks of the new application. Obviously this can't cover everything he needs to do - since the task is to create something new and unique, there can't possibly be building blocks around that cover every single detail. So at some point he'll have to fall back onto what some would regard the "real" work for a developer: start developing, i.e. analyzing problems, designing architecture, writing code.

In the XAF discussion forum, I have recently noticed a certain tendency. Customers will ask us for a way to solve a certain problem. We provide them with a solution, which of course in each instance is of varying elegance, but usually solves the problem. We see customers turn around and ask for the particular solution to be included in the default feature set of XAF. In this context, words like "workaround" or even "hack" are regularly used to describe the solution we provided, and hint at the understanding on the customer's side that this feature should surely be an integral part of XAF.

Think about this: if you wanted to create a simple Windows Forms application that let you handle a contact list, you could probably make use of some building blocks from the .NET framework. You'd be using standard controls, for instance, or perhaps ADO.NET to help you store the data. You might use third party controls to improve the UI experience. But in the end you'd also write code to implement that part of your functionality which is really the purpose of the whole application, which distinguishes this application from any other contact management application out there. It might be high-level code to collect all your closest friends from the complete collection of contacts, or it might be low-level code to facilitate certain visualization features beyond what the UI controls do by default. You have to write this code, because the .NET Framework doesn't provide you with ready-made building blocks to collect friends, or to do that creative visualization you have in mind. But the framework is flexible enough to let you reach your goals anyway, and in the process you have a chance of distinguishing yourself and your application and to create unique selling points for your application as well, things that perhaps other programmers can't implement or just don't have the ideas for.

Would you say that this code you're writing is a workaround or a hack, to accommodate the unfortunate fact that the .NET Framework doesn't have these features yet? I wouldn't say that.

In many of the cases I've seen in our forum, the features in question are really quite specific. If we wanted to include them in XAF, they'd have to be abstracted first, since it doesn't make sense to integrate a specific option, special class implementation or the like for every single use case out there, regardless of how often or rarely that use case applies. By implementing an abstraction of a feature, we widen the scope of use cases that can benefit from it. Of course, for every single one of our customers, this means that our abstracted feature doesn't solve the exact problem they're facing. Instead it enables a solution for that problem, which is then easier to achieve on the basis of a certain extent of framework support.

Does that sound familiar? It brings us back to the exact point where we already are right now. At this time, we have a very strong framework in our hands, which enables solutions to the vast majority of problems. There are steps a programmer has to make to apply those solutions to his own use cases. It speaks to the strength of the framework that this is possible, and it speaks to the imaginative skills of our support team that they can deliver these application specific solutions to you. So please don't call these use-case specific solutions workarounds or hacks. That's not what they are. What they really are is this: the creative part of your application that sets it apart from other applications. They are the valuable parts of your work that makes it your work instead of being something that anybody could have created by choosing some options from a list.

Can our framework be improved? It sure can. We're constantly looking out for things to include, problems to abstract, in order to enable further solutions in areas that weren't previously covered. We also look at things we can make easier, giving higher priority to those features that are used by most of our customers. But first and foremost we are in the business of providing a general purpose business application framework, and it is not a goal we have to allow any given specific application to be created only by clicking options with the mouse.

Free DevExpress Products - Get Your Copy Today