# Is it really impossible to choose between LINQ and Stored Procedures?

For the mathematician there is no Ignorabimus, and, in my opinion, not at all for natural science either. … The true reason why [no one] has succeeded in finding an unsolvable problem is, in my opinion, that there is no unsolvable problem. In contrast to the foolish Ignoramibus, our credo avers:
We must know,
We shall know.

It’s that time of the month again – when all of the evangelically inclined mavens of Readify gather round to have the traditional debate. Despite the fact that they’ve had similar debates for years, they tend to tackle the arguments with gusto, trying to find a new angle of attack from which to sally forth in defence of their staunchly defended position. You may (assuming you never read the title of the post 🙂 be wondering what is it that could inspire such fanatical and unswerving devotion? What is it that could polarise an otherwise completely rational group of individuals into opposing poles that consider the other completely mad?

What is this Lilliputian debate? I’m sure you didn’t need to ask, considering it is symptomatic of the gaping wound in the side of modern software engineering. This flaw in software engineering is the elephant in the room that nobody talks about (although they talk an awful lot about the lack of space).

The traditional debate is, of course:

What’s the point of a database?

And I’m sure that there’s a lot I could say on the topic (there sure was yesterday) but the debate put me in a thoughtful mood. The elephant in the room, the gaping wound in the side of software engineering is just as simply stated:

How do we prove that a design is optimal?

That is the real reason we spend so much of our time rehearsing these architectural arguments, trying to win over the other side. Nobody gets evangelical about something they just know – they only evangelise about things they are not sure about. Most people don’t proclaim to the world that the sun will rise tomorrow. But like me, you may well devote a lot of bandwidth to the idea that the object domain is paramount, not the relational. As an object oriented specialist that is my central creed and highest article of faith. The traditional debate goes on because we just don’t have proof on either side. Both sides have thoroughly convincing arguments, and there is no decision procedure to choose between them.

So why don’t we just resolve it once and for all? The computer science and software engineering fraternity is probably the single largest focussed accumulation of IQ points gathered in the history of mankind. They all focus intensively on issues just like this. Surely it is not beyond them to answer the simple question of whether we should put our business logic into stored procedures or use an ORM product to dynamically generate SQL statements. My initial thought was “We Must Know, We Will Know” or words to that effect. There is nothing that can’t be solved given enough resolve and intelligence. If we have a will to do so, we could probably settle on a definitive way to describe an architecture so that we can decide what is best for a given problem.

Those of you who followed the link at the top of the post will have found references there to David Hilbert, and that should have given you enough of a clue to know that there’s a chance that my initial sentiment was probably a pipe dream. If you are still in the dark, I’m referring to Hilbert’s Entscheidungsproblem (or the Decision Problem in English) and I beg you to read Douglas Hofstadter’s magnificent Gödel, Escher, Bach – An eternal golden braid. This book is at the top of my all-time favourites list, and among the million interesting topics it covers, the decision problem is central.

### The Decision Problem – a quick detour

One thing you’ll notice about the Entscheidungsproblem and Turing’s Halting Problem is that they are equivalent. They seem to be asking about different things, but at a deeper level the problems are the same. The decision problem asks whether there is a mechanical procedure to determine the truth of any mathematical statement. At the turn of the century they might have imagined some procedure that cranked through every derivation of the axioms of mathematical logic till it found a proof of the statement returning true. The problem with that brute-force approach is that mathematics allows a continual complexification and simplification of statements – it is non-monotonic. The implication is that just because you have applied every combination of the construction rules on all of the axioms up to a given length you can’t know whether there are new statements of the same length that could be found by the repeated application of growth and shrinkage rules that aren’t already in your list. That means that even though you may think you have a definitive list of all the true statements of a given length you may be wrong, so you can never give a false, only continue till you either find a concrete proof or disproof.

Because of these non-monotonic derivation rules, you will never be sure that no answer from your procedure means an answer of false. You will always have to wait and see. This is the equivalence between the Entscheidungsproblem and Alan Turing’s Halting Problem. If you knew your procedure would not halt, then you would just short-circuit the decision process and immediately answer false. If you knew that the procedure would halt, then you would just let it run and produce whatever true/false answer it came up with – either way, you would have a decision procedure. Unfortunately it’s not that easy, because the halting decision procedure has no overview of the whole of mathematics either, and can’t give an answer to the halting question. Ergo there is no decision procedure either. Besides, Kurt Gödel proved that there were undecidable problems, and the quest for a decision procedure was doomed to fail. he showed that even if you came up with a more sophisticated procedure than the brute force attack, you would still never get a decision procedure for all mathematics.

### The Architectural Decision Problem

What has this got to do with deciding on the relative merits of two software designs? Is the issue of deciding between two designs also equivalent to the decision problem? Is it a constraint optimisation problem? You could enumerate the critical factors, assign a rank to them and then sum the scores for each design? That is exactly what I did in one of my recent posts entitled “The great Domain Model Debate – Solved!” Of course the ‘Solved!‘ part was partly tongue-in-cheek – I just provided a decision procedure for readers to distinguish between the competing designs of domain models.

One of the criticisms levelled at my offering for this problem was that my weights and scores were too subjective. I maintained that although my heuristic was flawed, it held the key to solving these design issues because there was the hope that there are objective measures of the importance of design criteria for each design, and it was possible to quantify the efficacy of each approach. But I’m beginning to wonder whether that’s really true. Let’s consider the domain model approach for a moment to see how we could quantify those figures.

Imagine that we could enumerate all of the criteria that pertained to the problem. Each represents an aspect of the value that architects place in a good design. In my previous post I considered such things as complexity, density of data storage, performance, maintainability etc. Obviously each of these figures varies in just how subjective it is. Complexity is a measure of how easy it is to understand. One programmer may be totally at home with a design whereas another may be confused. But there are measures of complexity that are objective that we could use. We could use that as an indicator of maintainability – the more complex a design is, the harder it would be to maintain.

This complexity measure would be more fundamental than any mere subjective measure, and would be tightly correlated with the subjective measure. Algorithmic complexity would be directly related to the degree of confusion a given developer would experience when first exposed to the design. Complexity affects our ability to remember the details of the design (as it is employed in a given context) and also our ability to mentally visualise the design and its uses. When we give a subjective measure of something like complexity, it may be due to the fact that we are looking at it from the wrong level. Yes, there is a subjective difference, but that is because of an objective difference that we are responding to.

It’s even possible to prove that such variables exist, so long as we are willing to agree that a subjective dislike that is completely whimsical is not worth incorporating into an assessment of a design’s worth. I’m thinking of such knee-jerk reactions like ‘we never use that design here‘ or ‘I don’t want to use it because I heard it was no good‘. Such opinions whilst strongly felt are of no value, because they don’t pertain to the design per-se but rather to a free-standing psychological state in the person who has them. The design could still be optimal, but that wouldn’t stop them from having that opinion. Confusion on the other hand has its origin in some aspect of the design, and thus should be factored in.

For each subjective criterion that we currently use to judge a design, there must be a set of objective criteria that cause it. If there are none, then we can discount it – it contributes nothing to an objective decision procedure – it is just a prejudice. If there are objective criteria, then we can substitute all occurrences of the subjective criterion in the decision procedure with the set of objective criteria. If we continue this process, we will eventually be left with nothing but objective criteria. At that point are we in a position to choose between two designs?

### Judging a good design

It still remains to be seen whether we can enumerate all of the objective criteria that account for our experiences with a design, and its performance in production. It also remains for us to work out ways to measure them, and weigh their relative importance over other criteria. We are still in danger of slipping into a world of subjective opinions over what is most important. We should be able to apply some rigour because we’re aiming at a stationary target. Every design is produced to fulfil a set of requirements. Provided those requirements are fulfilled we can assess the design solely in terms of the objective criteria. We can filter out all of the designs that are incapable of meeting the requirements – all the designs that are left are guaranteed to do the job, but some will be better than others. If that requires that we formally specify our designs and requirements then (for the purposes of this argument) so be it. All that matters is that we are able to guarantee that all remaining designs are fit to be used. All that distinguishes them are performance and other quality criteria that can be objectively measured.

Standard practice in software engineering is to reduce a problem to its component parts, and attempt to then compose the system from those components in a way that fulfils the requirements for the system. Clearly there are internal structures to a system, and those structures cannot necessarily be weighed in isolation. There is a context in which parts of a design make sense, and they can only be judged within that context. Often we judge our design patterns as though they were isolated systems on their own. That’s why people sometimes decide to use design patterns before they have even worked out if they are appropriate. The traditional debate is one where we judge the efficacy of a certain type of data access approach in isolation of the system it’s to be used in. I’ve seen salesmen for major software companies do the same thing – their marks have decided they are going to use the product before they’ve worked out why they will do so. I wonder whether the components of our architectural decision procedure can be composed in the same way that our components are.

In the context that they’re to be used, will all systems have a monotonic effect on the quality of a system? Could we represent the quality of our system as a sum of scores of the various sub-designs in the system like this? (Q1 + Q2 + … + Qn) That would assume that the quality of the system is the sum of the quality of its parts which seems a bit naive to me – some systems will work well in combination, others will limit the damage of their neighbours and some will exacerbate problems that would have lain dormant in their absence. How are we to represent the calculus of software quality? Perhaps the answer lies in the architecture itself? If you were to measure the quality of each unique path through the system, then you would have a way to measure the quality of that path as though it was a sequence of operations with no choices or loops involved. You could then sum the quality of each of these paths weighted in favour of frequency of usage. That would eliminate all subjective bias and the impact of all sub designs would be proportional to the centrality of its role within the system as a whole. In most systems data access plays a part in pretty much all paths through a system, hence the disproportionate emphasis we place on it in the traditional debates.

### Scientific Software Design?

Can we work out what these criteria are? If we could measure every aspect of the system (data that gets created, stored, communicated, the complexity of that data etc) then we have the physical side of the picture – what we still lack is all of those thorny subjective measures that matter. Remember though that these are the subjective measures that can be converted into objective measures. Each of those measures can thus be added to the mix. What’s left? All of the criteria that we don’t know to ask about, and all of the physical measurements that we don’t know how to make, or don’t even know we should make. That’s the elephant in the room. You don’t know what you don’t know. And if you did, then it would pretty immediately fall to some kind of scientific enquiry. But will we be in the same situation as science and mathematics was at the dawn of the 20th Century? Will we, like Lord Kelvin, declare that everything of substance about software architecture is known and all the future holds for us is the task of filling in the gaps?

Are these unknown criteria like the unknown paths through a mathematical derivation? Are they the fatal flaw that unhinges any attempt to assess the quality of a design, or are they the features that turns software engineering into a weird amalgam of mathematics, physics and psychology? There will never be any way for us to unequivocally say that we have found all of the criteria that truly determine the quality of a design. Any criteria that we can think of we can objectify – but it’s the ones we can’t or don’t think of that will undermine our confidence in a design and doom us to traditional debates. Here’s a new way to state Hilbert’s 10th Problem:

Is there a way to fully enumerate all of the criteria that determine the quality of a software design?

Or to put it another way

Will we know when we know enough to distinguish good designs from bad?

The spirit of the enlightenment is fading. That much is certain. The resurgence of religiosity in all parts of the world is a backward step. It pulls us away from that pioneering spirit that Kant called a maturing of the human spirit. Maturity is no longer needing authority figures to tell us what to think. He was talking about the grand program to roll back the stifling power of the church. In software design we still cling to the idea that there are authority figures that are infallible. When they proclaim a design as sound, then we use it without further analysis. Design patterns are our scriptures, and traditional wisdom the ultimate authority by which we judge our designs. I want to see the day when scientific method is routinely brought to bear on software designs. Only then will we have reached the state of maturity where we can judge each design on its objective merits. I wonder what the Readify Tech List will be like then?

# Converting Jena to .NET

I spent most of my evening converting Jena to .NET. Needless to say it was only at the end of the evening that I discovered that Andy Seabourne (from my old home town of Bristol) had already worked out how to use IKVM to convert the jar files into assemblies. I’m not bothered though; I produced make files (rather than shell scripts) that work better on cygwin. The best thing I got from Andy was his “don’t worry be happy” advice that IKVM spuriously complains about unfound classes – you don’t need to worry about it. Once I read that, I realised that I had successfully converted Jena about 4 hours earlier, and all my fiddling about trying to get the right pattern of dependencies was completely unnecessary – IKVM just works! (and rocks)

Had I realised just how easy it was to convert bytecode to IL, I might have gone trawling the apache jakarta project more often over the last few years. (sigh) Never mind – I now have the tools for working on semantic web applications in .NET. Yayyyy!!!! I don’t have to learn Python either. I’m not sure whether I’m sad about that.

I don’t have a place handy to put the assemblies, and wordpress won’t allow me to upload them, so I’ll do the next best thing and give you the make file. It assumes that you are using cygwin or something similar. If you aren’t just use the conventional windows path structure for ikvmdir. It also is based on Jena version 2.5.2. Continue reading

# Are You Sublime or Ridiculous?

Sometimes I wonder at the simplicity of us humans. Its often hard to see the simplicity though, when we act in such complex ways, but I think the following describes our ‘behaviour‘ quite succinctly.

$.8x/x^\frac{8-x}{x}$

Pretty simple huh? Well it looks a bit like this when you draw a graph:

See what I mean? You sate a need, and over time its intensity increases till it starts to get unbearable. Obviously this graph represents my dependency on caffeine, and is based on entirely randomly chosen numbers, scales & so on. But you get the picture? It’s fairly indicative of how we react if we don’t attend to our needs over time.

You may be wondering why (in addition to taking a rather dismal tone in this post) on earth I felt the urge to create such a model. Well the answer is (in addition to giving me a chance to play with gnuplot, mathomatic and $\LaTeX$ all in the one post) that I’m producing the rules to go with the little Freudian drive ontology I showed you in my previous post. There, in the 20-odd lines of N3 notation, I was able to produce a nice little model of our baser urges – what you might call our reptilian heritage 🙂

What amuses me is that we can describe such deeply felt aspects of our personalities in such simple terms. I mean, that equation earlier wasn’t that complex was it? It’s not like it needed quaternions or new fields of analysis! It reminds me of a blog post I read a few months back by some guy who’d discovered how to initiate a transition in the state model of his grizzly daughter. Whenever she started to cry, and he or his wife couldn’t console her, they put her into her cot. After a while she forgot why she was crying (remember FSAs are stateless:) and so when they lifted her out of her cot, she immediately thought she’d gotten what she wanted and stopped crying. She’d transitioned from in_cot/[Cry] to the out_of_cot/[Smile] state.  It also made me remember that the common house-fly’s visual navigation algorithm is about as complex as the equation I just gave. It’s not that the algorithm is complex, but that the environment it reacts to is.

So, are you a meaty algorithm, or the pinnacle of god’s creation? Me? I’m just off for a coffee and a fag, before going to sleep. 🙂

# Domain Modeling and Ontology Engineering

The semantic web is poised to influence us in ways that will be as radical as the early days of the Internet and World Wide Web. For software developers it will involve a paradigm shift, bringing new ways of thinking about the problems that we solve, and more-importantly bringing us new bags of tricks to play with.

One of the current favourite ways to add value to an existing system is through the application of data mining. Amazon is a great example of the power of data mining; it can offer you recommendations based on a statistical model of purchasing behaviour that are pretty accurate. It looks at what the other purchasers of a book bought, and uses that as a guide to make further recommendations.

What if it were able to make suggestions like this: We recommend that you also buy book XYZ because it discusses the same topics but in more depth. That kind of recommendation would be incredible. You would have faith in a recommendation like that, because it wasn’t tainted by the thermal noise of purchaser behaviour. I don’t know why, but every time I go shopping for books on computer science, Amazon keeps recommending that I buy Star Trek books. It just so happens that programmers are suckers for schlock sci-fi books, so there is always at least one offering amongst the CompSci selections.

The kind of domain understanding I described above is made possible through the application of Ontology Engineering. Ontology Engineering is nothing new – it has been around for years in one form or another. What makes it new and exciting for me is the work being done by the W3C on semantic web technologies. Tim Berners-Lee has not been resting on his laurels since he invented the World Wide Web. He and his team have been producing a connected set of specifications for the representation, exchange and use of domain models and rules (plus a lot else besides). This excites me, not least because I first got into Computer Science through an interest in philosophy. About 22 years ago, in a Sunday supplement newspaper a correspondent wrote about the wonderful new science of Artificial Intelligence. He described it as a playground of philosophers where for the first time hypotheses about the nature of mind and reality could be made manifest and subjected to the rigours of scientific investigation. That blew my mind – and I have never looked back.

Which brings us to the present day. Ontology engineering involves the production of ontologies, which are an abstract model of some domain. This is exactly what software developers do for a living, but with a difference. The Resource Description Framework (RDF) and the Web Ontology Language (OWL) are designed to be published and consumed across the web. They are not procedural languages – they describe a domain and its rules in such a way that inference engines can reason about the domain and draw conclusions. In essence the semantic web brings a clean, standardised, web enabled and rich language in which we can share expert systems. The magnitude of what this means is not clear yet but I suspect that it will change everything.

The same imperatives that drove the formulation of standards like OWL and RDF are at work in the object domain. A class definition is only meaningful in the sense that it carries data and its name has some meaning to a programmer. There is no inherent meaning in an object graph that can allow an independent software system to draw conclusions from it. Even the natural language labels we apply to classes can be vague or ambiguous. Large systems in complex industries need a way to add meaning to an existing system without breaking backwards compatibility. Semantic web applications will be of great value to the developer community because they will allow us to inject intelligence into our systems.

The current Web2.0 drive to add value to the user experience will eventually call for more intelligence than can practically be got from our massive OO systems. A market-driven search for competitiveness will drive the software development community to more fully embrace the semantic web as the only easy way to add intelligence to unwieldy systems.

In many systems the sheer complexity of the problem domain has led software designers to throw up their hands in disgust, and opt for data structures that are catch-all buckets of data. Previously, I have referred to them as untyped associative containers because more often than not the data ends up in a hash table or equivalent data structure. For the developer, the untyped associative container is pure evil on many levels – not least from performance, readability, and type-safety angles. Early attempts to create industry mark-up languages foundered on the same rocks. What was lacking was a common conceptual framework in which to describe an industry. That problem is addressed by ontologies.

In future, we will produce our relational and object oriented models as a side effect of the production of an ontology – the ontology may well be the repository of the intellectual property of an enterprise, and will be stored and processed by dedicated reasoners able to make gather insights about users and their needs. Semantically aware systems will inevitably out-compete the inflexible systems that we are currently working with because they will be able to react to the user in a way that seems natural.

I’m currently working on an extended article about using semantic web technologies with .NET. As part of that effort I produced a little ontology in the N3 notation to model what makes people tick. The ontology will be used by a reasoner in the travel and itinerary planning domain.
 :Person a owl:Class . :Need a owl:Class . :PeriodicNeed rdfs:subClassOf :Need . :Satisfier a owl:Class . :need rdfs:domain :Person; rdfs:range :Need . :Rest rdfs:subClassOf :Need . :Hunger rdfs:subClassOf :Need . :StimulousHunger rdfs:subClassOf :Need . :satisfies rdfs:domain :Satisfier; rdfs:range :Need . :Sleep a :Class; rdfs:subClassOf :Satisfier ; :satisfies :Rest . :Eating a :Class; rdfs:subClassOf :Satisisfier; :satisfies :Hunger . :Tourism a :Class; rdfs:subClassOf :Satisisfier; :satisfies :StimulousHunger .

In the travel industry, all travel agents – even online ones – are routed through centralised bureaus that give flight times, take bookings etc.  The only way that an online travel agency can distinguish themselves is if they are more smart and easier to use. They are tackling the later problem these days with AJAX, but they have yet to find effective ways to be more smart. An ontology that understands people a bit better is going to help them target their offerings more ‘delicately’. I don’t know about you, but I have portal sites that provide you with countless sales pitches on the one page. Endless checkboxes for extra services, and links to product partners that you might need something from. As the web becomes more interconnected, this is going to become more and more irritating. The systems must be able to understand that the last thing a user wants after a 28 hour flight is a guided tour of London, or tickets to the planetarium.

The example ontology above is a simple kind of upper ontology. It describes the world in the abstract to provide a kind of foundation off which to build more specific lower ontologies. This one just happens to model a kind of Freudian drive mechanism to describe how people’s wants and desires change over time (although the changing over time bit isn’t included in this example). Services can be tied to this upper ontology easily – restaurants provide Eating, which is a satisfier for hunger. Garfunkle’s restaurant (a type of Restaurant) is less than 200 metres from the Cecil Hotel (a type of Hotel that provides sleeping facilities, a satisfier of the need to rest) where you have a booking. Because all of these facts are subject to rules of inference, the inference engines can deduce that you may want to make a booking to eat at the hotel when you arrive, since it will have been 5 hours since you last satisfied your hunger.

The design of upper ontologies is frowned upon mightily in the relational and object oriented worlds – it smacks of over-engineering. For the first time we are seeing a new paradigm that will reward deeper analysis. I look forward to that day

Stumble It!

# Linguistic development

Child Linguistic Development is a document that I wrote when I was at university on the stages of language development. Since Emily and Thomas are now a week short of 18 months it is time for Kerry and I to start learning about learning. I’d forgotten most of this stuff, so it will make interesting reading for me too! I’ve put a link in to kerry’s gorgeous new blog/journal, where she describes her day-to-day experiences of raising twins. Hair raising more than twin raising, if you want my opinion…

# Do I say anything worthwhile in this blog? « Alec the Geek

Alec recently agonized about whether he says anything worthwhile in his blog, or whether a blog was the right medium for the kind of things he wanted to say:

Do I say anything worthwhile in this blog? « Alec the Geek

Well, the short answer is an unqualified ‘yes‘.

The long answer (based on our own experiences) is that simplistic mainstream trolls or opinion pieces will attract more passing traffic than a carefully thought out, meticulously planned, thrice-proof-read epistles. Keeping your posts short and sweet, and simple for the lowest common denominator in the audience would seem to be the way to go.

That’s if all you cared about was site hits. But that misses the point. If your interests are niche interests, and if they are too technically demanding to draw a large crowd, does that make them any the less worthy? Of course not. In fact the more niche they are, and the more care you put into their production, the higher the information content. The web needs a higher signal to noise ratio, and it can only get that if well-informed and thoughtful people write in depth about whatever they want.

Keep up the good work, dude.

# The Greate Domain Model Debated – Continued.

I recently got this excellent comment from Jeff Grigg on my domain model debate article. I started to reply with a comment, but the reply got to the point where it became a bit of a blog post in its own right, so I thought it worth giving it first class status. Jeff wrote this:

Interesting concept: I particularly like the concept of using numeric weights and rankings, rather than just claims of preference. But we need to realize that we can use numbers to express our level of subjective feelings, and that doing so doesn’t make the results objective.

I notice that, according to your numbers, the top two recommended approaches are: (#1) Anemic Domain Model, and (#2) Rich Domain Model, with all others trailing behind these. The difference between the top two is about 10% of the difference between the top and bottom (best and worst) approaches. So I’d say that even you’re numbers aren’t a strong argument against using RDM; they only show a moderate advantage of ADM, while showing that RDM is still better than anything else (other than ADM).

About 46% of the difference between ADM and RDM is that you feel that ADM is twice as “encapsulatable.” I think it would be helpful to have a better idea of what you mean by the values, like “encapsulatable.” When I consider how well a class encapsulates its fields, I use the information hiding principles, concluding that an ADM object that exposes all fields with getters and setters is not well encapsulated, while a RDM object that hides its fields and exposes only operations is very well encapsulated.

For about 23% of the difference between ADM and RDM, you feel that ADM is nearly twice as maintainable. My experience has generally been the opposite: For example, when interpretation and enforcement of codes and states is distributed throughout all the procedural modules that use a record, rather than centralized and encapsulated in the class that represents that record, then ensuring that all actions conform to the rules and changing the rules can be difficult, costly and risky.

(For completeness, the remaining differences are: technological intrusiveness (15%), complexity of programming model (11%), and ease of extensibility (5%).)

One last thought about the numbers: I find it interesting that “naked objects” gets a much different and much worse score than either ADM or RDM; only three others scored worse. I find this interesting because the Naked Objects Framework, which you link to in your article (see http://nakedobjects.org/ for more info) is based heavily on the assumption that you will build a Rich Domain Model: With Naked Objects, there are no additional layers of logic between the GUI and the domain model, so unless all operations the user is interested in are in the domain model, the user will not be able to invoke them. And unless the operations are directly on the relevant business domain classes, the system will probably be difficult and confusing to use.

Overall, I found this article and in particular your approach interesting and informative. I like the ideas; I just don’t agree with the conclusions.