I love my granny, as all of us who are fortunate enough still to have one alive do I’m sure. My granny hails from Highland Perthshire and is, as we say in Scotland, of farming stock; that is to say that, before retiring, she worked a farm, as her forebearers before her did. This means, amongst other things, that she has a wealth of homespun advise, neatly packaged up into handy little sayings, each one perfect for a particular set of circumstances. For example
“Oh, look at the time and there’s no’ a carrot in the pot!”
Meaning that the day is slipping away and it looks like I might not get through all the tasks I had allocated to do today, and
“Behave yersel’ else I’ll come in aboot yer wa’s wi a tarry stick”
Which means if you do not moderate your bahaviour I’ll beat you about the ribs with the stick I use to stir the molasses for the cattle feed. However, one of my favourites, and one which is somewhat applicable to the situation I now find myself in, is
“It’s the squeaky wheel that gets the oil”
Meaning it’s the thing (or person) that makes the most noise (or complains loudest) that gets dealt with fastest. I say it is somewhat applicable to the situation that I now find myself in because, whilst taking my habitual morning “stroll” through our forums, I came across a post, in which the writer was praising Mark’s recent set of posts, showing how to write a plugin using DXCore, and wondering aloud why the XAF team couldn’t be more like Mark, and produce such real world examples.
Of course, if the writer had appreciated that DXCore and XAF/XPO cannot be compared like for like, he would have been a long way to answering his own question. You see, DXCore is an enabling technology facilitating the creation of a certain type of plugin, it does one thing, and it does it very well and so writing a real world example is easy, as each user’s view of the “world” is the same.
XAF however, is an application framework, allowing a developer to create winform or webform (or both) applications; it is strategic software that lays out the architectural steps for a developer, the tactical code that the developer then adds to that base, to form the solution to his business problem, is utterly dependent upon a myriad of things:- the industry, the sector of the industry, his company’s view of their market place, financial constraints on his company, financial constraints on his customers, etc, etc, etc; the list goes on and on.
The point being that there is not one “real world” from which to construct a “real world” example, instead the term takes its definition dependent upon the context of the individual developer. Take me as an example, before joining DevExpress I worked, for 18 years, as a programmer and architect in a number of industries including: Banking, Utilities, FMCG, Pharmaceuticals and Local Government. I can tell you that if you took an application from each of those industries and compared them, they would have little in common. In fact you would have to distil them down to their architectural parts (object persistence, reporting, etc.) before you would find much similarity. So any “real world” example, if it were to be of use to all of our customers equally, can only contain examples of how to use these architectural parts (or product features if you will). It’s no coincidence then, that our MainDemo application demonstrates these product features in a somewhat isolated way, it has to be that way to be of use to our customers as a whole. Again, it is no accident that our documentation takes the same approach of explaining the product features in this way.
But the “squeaky wheel” says “it’s hard to find information in your documentation”, so I begin a series of cookbook style posts that state a problem, in very simple terms, and then show the solution and a discussion of that solution. The “squeaky wheel” says “these posts are too simplistic” so I suggest a more advanced series, still in the cookbook style, to make it easy to find, called Black Belt XAF and I ask for topic suggestions. The majority of suggestions I receive are not XAF topics but general architectural topics (which I have no objections to covering if that is of benefit to our customers). The “squeaky wheel” says “these examples are not real world”. Although I’ve explained above how it is nearly impossible for us to provide “real world” examples, I decided to start a “Starring You” section in my blog so that actual real world customers can post actual real world examples and they are starting to come through now and yet the post above calls for the XAF team to provide more “real world examples”.
I contemplated this for a few minutes before I dismissed the idea, I mean how ridiculous. If I were to write a series of blog posts showing how to build a solution from the Banking industry or from the Utilities industry, for example, it would only be useful for a vanishingly small percentage of our customers. Then I thought, wait a minute, maybe this is where I’m going wrong, making assumptions about how useful something would be, why not just ask them? So here we are; the “squeaky wheel” says we need to write a “real world” application and I’m asking you, if I were to create such an application, from start to finish, and even though the chosen industry may have little in common with yours, would that help you? If so, leave a comment below.
Technorati tags:
XAF,
Community