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.

Tags
6 comment(s)
Reinhold Erlacher

Hi Oliver,

you are right, when you tell us to not call code for specific problems "hacks or workarounds". But would you agree when I call code, that we need to write to "fully" integrate your own controls in XAF, a workaround?

I'm talking of three requests, which are open since a while now:

a) Master/Detail-Integration in XAF for XtraGrid

b) Reminder Support for XtraScheduler

c) Recurrence Support for XtraScheduler.

I think, these features are of common interest (otherwise they wouldn't be part of a component you sell) and therefore priortiy to unleash these features in XAF should be "Very High".

thanks

reinhold

1 May, 2008
Oliver Sturm (DevExpress)

Hi Reinhold,

To me, a workaround would be an approach I have to take, perhaps a piece of code I have to write (or rather, the particular way I have to write a piece of code?), because something isn't working as it should. Then again, this is a fine line - the reason why something doesn't work as it should is important, for instance - who defines what "should" be, after all? Implementing a missing feature myself, under any circumstances, is not a workaround in my book.

I'm not saying we never suggest workarounds - we do, all the time, for example in the case of bugs. Workarounds always have temporary character - "I do it this way due to bug X49827, and I'll change it back once this gets fixed".

With regard to those particular problems you are mentioning - I believe you picked those out because they are among the few issues we see with XAF where the basic implementation we provide isn't sufficient to enable a feature to be implemented. Or at least the effort required to implement the feature is obviously too great. To try and answer your question - if anybody actually managed at this point to make reminders or recurrence work fully, then that would obviously be a feature, right? A feature that will hopefully one day be available out of the box.

I was just thinking whether it would make sense for me to write another post that more clearly defines the definitions I use here. But I think in the end that's not necessary - most of us have pretty similar definitions anyway. As I said, a workaround sounds like something temporary, and if people sometimes use that word to describe what is really a feature implementation to me, then that means they think it should be part of the product. Well, nothing wrong with suggesting that - my post was meant, among other things, to describe the various points of view there can be on this topic.

1 May, 2008
Mohsen Benkhellat

I agree that adding new functionality by extending that of XAF is not a workaround. But there are still areas where the suggested solutions by DX are hacks like in:

1- In XAF, reusing the same List schema definition in model to describe any type of list while actually there might be important differences depending on the control used to implement the list editor. Think of GridEditor and TreeListEditor where Group index does mean something for the grid and menas nothing for the treelist.

2- In XtraPivot/AspxPivotGrid where inconsitencies in core and UI bent classes/Interfaces/namespaces/assemblies make it tiring to share logic for both pivot grids (Win and Web),

3-In PivotGrid again, I had to flaten my hierarchies (ID_ParentID) in order to use the pivot because it does not support auto-referencing associations.

One can always say that it is my part of the job at hand to make it my app and DX's app and I can not deny this fact ;-)

Mohsen

1 May, 2008
Oliver Sturm (DevExpress)

Hi Mohsen,

I don't really want to start a detailed discussion in the comments here. Suffice it to summarize from my perspective that (1) is based on the strict layering that XAF uses - certainly an area that can be perfected, but equally certainly a very elegant solution to begin with, (2) sounds almost like a bug, without looking into too many details, but of course not really related to XAF at all and (3) seems to be a missing feature in the XtraPivotGrid (a known one btw, I remember talking about this ages ago when the product was really new).

There's never anything wrong with discussing these things. We want to know your opinions, and if you want to use the approach of calling solutions workarounds in order to make us understand that you don't regard them as perfect, that's fine in general. We can interpret that to understand where you're coming from. But we disagree with the "workaround" or "hack" understanding regularly, and an objective discussions is always harder to manage if one party uses extreme vocabulary, belittles efforts other parties make and so on. To some extent my post is a reflection on the art of human interaction, or perhaps just on the idea that it is, in fact, an art form.

2 May, 2008
Vadim Katsman

After a week of frustrated chasing few inconsistencies in ASPxGridView control placed inside ASPxCallbackPanel I decided to put my few cents into this discussion.

Coding is not workaround.  The coding to overcome unknown (undocumented) limitation of the advertised functionality - is.  

Also, using functionality outside the library is not workaround.  But if you need hack into the internal (not documented) details of the output produced by the library - is.   When the developer does not depend on the library, he or she designs usage of the underlying technology and this is normal chain of events.  When you depend on the library, the library becomes part of the underlying technology, such integrated library as DevExpress becomes the platform on its own and the custom code needs to follow the library guidelines to produce an integrated output, a lot of code is focused not to add new functionality or to address the business logic specifics but (again) hacks to do an artificial tricks to hook up with the library output (simply because of library wants in certain way) or (which is even worse) a lot of code is focused to overcome inconsistencies, limitations and defects of the library.  And this is clear workaround.

Just a simple example.  Usage of HtmlRowCreated vs. HtmlDataRowPrepared vs. HtmlDataCellPrepared events.  The advertised feature recommends to use the last event to make custom HTML adjustments to the content of the data cell.  However, in certain callbacks situation that works initially and stops after the very first callback.  Putting the same code into HtmlRowCreated event was not an documented approach but worked (using your own staff example).  Is that coding or workaround?  Coding if we add new functionality not planned to be provided by the library or spesific to the particularity of the application we are writing.  The code tricks we have to overcome within the domain of library output are workarounds.

As soon as library is grown up beyond few intruments that enhance existing tools into platform / framework, any coding around its standard flow become workarounds (whether recommended or documented or not) - they are not workarouds if the target output of that code pieces lies within the domain of the framework output itself.

10 June, 2008
eXpress App Framework Team

This is post no. 4 in the mini series "10 exciting things to know about XAF". You can find

1 February, 2012

Please login or register to post comments.