Archive for March, 2007

## 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. Read more

## 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.

I didn’t want the model to be interpreted as objective truth, rather as a means for me to determine whether ADM really was the best choice for me (on the kinds of projects I’ve been working with). I thought it possible that I might have scored some other technique higher, and thus should abandon ADM as my preferred choice. I guess this was a long shot, but until I gave it sufficiently systematic thought I wasn’t going to be able to say with any confidence that I thought that ADM is what you ought to be using.

I also wanted to make it clear that (for any given designer) it is possible to express opinions in a way that (as you so clearly demonstrated) others can easily highlight deficiencies in. Blogging is such a linear medium that I would have had to write an endless succession of posts to cover the kind of material I did in those two images! I think that would have taxed even the most patient of my readers. Being able to clearly express my thoughts in terms of a numerical weight means that you can easily compare the performance or maintainability of two techniques and take issue with my assessment. If your arguments are persuasive, then I can at the very least update my spreadsheet. For example, I will revisit the Naked Objects framework, and give it another try, since it’s clear I didn’t get the whole picture when I first read about it. It’s possible that the framework has undergone a lot of refinement in the time since I read about it, and is now more worthy of attention than it was. I can’t think of a better way (short of blogging to excess on minutiae) to get that kind of broad picture of a person’s experiences with object modelling than for them to score a model like this.

Given a broadly agreed set of benchmarks, it might be possible to add a level of objectivity to the figures. It must be said that most of the papers I’ve ver read on the efficacy of certain software engineering practices were little more than folklore. That is especially true in the case of the maintainability of software systems. If a design doesn’t interfere with the efforts of the maintenance programmers assigned to it does that mean that (1) the design was good, (2) the maintainers were the original developers, (3) the maintainers were very experienced with such designs. It’s clear that most information we have about the efficacy of programming and design techniques is for the most part anecdotal (even when dressed up in academic guise) and is of little more worth than our own personal experience of working with the code of others. We could really benefit from a degree of objectivity in these issues – there are so many orthogonal criteria on which a design can be judged. the problem is that measuring how well a design performed on each criteria is largely a subjective measurement. How can we find a way to get objectivity out of a comparison of design methods. Those do a cook off, and then interview the developers afterwards studies are not very useful. And of course you can get the same developers to do the project again using different techniques – they’d find the project too easy the second time round because all the problems were familiar.

What I wanted was to create a simple way to help people to think for themselves about the domain model debate. I’ve recently been listening to a great podcast about the enlightenment by Thomas Lacqueur, and one particular idea stuck with me which I think pertains to the current issue. Kant said that the enlightenment movement was a maturing of the consciousness of the population. Maturity for him meant not looking to an authority figure for guidance, but instead working solutions out for yourself. In his case he was referring to religion, and statecraft, but I think the principle applies equally well now. We should seek ways to make our own minds up, or at least have a truly solid objectively measurable argument in favour of a design principle rather than just endorsement by famous designers. Just because XYZ designer disparages ADM, does that mean we should abandon it? Not necessarily, we should first look at his or her reasons and what kind of projects they were using it for.

It sometimes seems to me that opinioneers are what they are because we require it of them. They have to have an opinion, and as time goes by those opinions have to get more extreme to be heard above the background noise. That is not currently as true in the object oriented design community as it is in the arena of politics, but the more people blindly follow design guidance the more it will become so.

Follow the tradition of the enlightenment – make your own mind up, and feel free to use or expand on my spreadsheet to do so. And if you can’t see my spreadsheet properly, then blame wordpress for only putting out narrow stylesheets.

## Here is your enemy…

Click this link to see the single largest threat to democracy the world is currently facing. This bunch of evil techno-terrorists is ravening at the gates of western civilization. You have every right to fear these people. Their military might fought America to a standstill. How can we withstand such an enemy? These crack commandos are hiding in plain sight disguised as CAMELS!

Or, to put it another way :-

Images this precise must have been taken just prior to a bomb landing on this terrorist training ground.

## Singleton – the most overused pattern.

Recently within Readify we’ve been discussing the results of some code reviews we’d done with some of our clients. One issue that came to light was the issues introduced by the excessive use of the singleton pattern. If you’re not familiar with patterns, it’s quite simple. Patterns are a kind of reusable design. The original and most famous book (commonly called the Gang of Four book or just GoF) was itself inspired by the Pattern Language book by Christopher Alexander. Alexander was a bricks and mortar architect, who realized that there were common factors found in all buildings that were livable. There were, he concluded, common groups of solutions that addressed the same problems, and that when used together could provide a proven solution that had been shown to work in the past. His work was the first attempt to codify the common wisdom of not just highly paid US architects but the traditional wisdom of indigenous societies. His solutions worked whether applied to a mud hut, a stucco villa or a high-rise apartment. The GoF realized that they could codify the common designs in use in the software development community in the same way – by describing the outline of the problem that it seeks to solve, the forces that determine whether the solution will fit, and a typical implementation. The Singleton pattern is one of those first few GoF patterns and is probably the most commonly applied.

The Singleton pattern uses static access rules to control the way in which objects are constructed for a type. That is to say, they provide one place to get an instance of an object, and that place dispenses copies that are shared by all. Here’s a typical implementation of Singleton:

public sealed class SingletonClass { private static readonly SingletonClass instance = new SingletonClass(); private SingletonClass(){/*…*/} public static SingletonClass Instance {     get{return instance;} } // … }

The current best practice suggests that you should attempt to make your business logic classes stateless. You should be able to create as many of them as you like, and use them concurrently. They should probably be static in scope. That has a few implications of its own. If the class is stateless then you cannot use it to store intermediate results of calculations unless you can guarantee that you are the only holder of the object, and that object is never accessed until you’ve finished doing whatever it is that you are going with it. That frequently means that you should be able to do whatever you need to do from within a single call. The alternative is what is called a ‘chatty‘ interface. That sort of design uses multiple calls to establish a consistent state before commencing a transaction. You get this a lot when you have something like a wizard form gathering data and passing it on to someone else before going on to the next page. The drawback is that the instance that stores the data has to be kept around, or the data has to be persisted somewhere, despite the fact that it is incomplete. It is much better to cache the data somehow in the presentation tier before passing it to your business logic for processing.

Another name for a business object method is transaction script, which I think exemplifies what you should be aiming for. A transaction script gets all of its data and enacts the transactions required to change the system state (I’m not just talking about databases here – see Sutter for a discussion of exception management and consistency). If you don’t give it all the data that it needs to complete the transaction then you will either have to leave the database in an inconsistent state till the last data arrives, or you will have to maintain long-running transactions which will place stress on the database’s resources.

A singleton is a special case of an object pool. An object pool dispenses objects and potentially manages their lifecycle and state to a certain extent. Often a pool will recycle objects, return their state to a default state and generally clean up after an object has been used. You can see that in comparison to an object pool such as in .NET Enterprise Services, a singleton as shown above is actually quite a degenerate specimen. It does no recycling, cleanup or queuing. Users just get a reference to share with everyone else, and the devil take the hindmost! The singleton pattern, if to be used in a multithreaded environment, should be used with real understanding of risks involved.

So you see, an innocent little singleton in you middle tier is not so innocent after all. Don’t use it unless you are forced to.

For for a good description that explains how you ought to implement the singleton, visit Jon Skeet’s excellent article on the subject.

## New Features in Visual Studio Orcas

I’ve been taking the new Visual Studio Preview for a spin, and it’s got some pretty nice new additions. These aren’t just the headline features that have been publicized elsewhere, but the thoughtful additions to usability that will make our lives a little bit easier. They should also help us to make our code a lot cleaner and less complex. We see the introduction of easy performance reporting and differential comparison of profiling sessions. We also see the introduction of code metrics analysis. The March 2007 CTP also sees the long awaited intellisense support for LINQ in C# as well as some other nice features for exporting code and projects as templates.

The performance report comes with a single click. It helps you to target your optimizations.

After you’ve done your optimizations, you can rerun your profiler and do a comparison to see how well your efforts worked.

The code analysis tools now offer code complexity metrics that will indicate whether your code needs simplification or refactoring.

The refactoring tools have not received much attention, and still lag behind the likes of R#. There are a quite a few refactoring code snippets, that may allow us to craft our own refactorings. If so, then we have a power that has not been seen outside of UML tools like Rational XDE.

The tools for architects have come along way. It’s clear that they are targeting the aims of the Dynamic Systems Initiative (DSI). This is a very exciting piece of work, and will revolutionize development when it reaches fruition. Here you can see an Application diagram with a set of property pages allowing the architect to define the system properties required for deployment of a windows application called Test1.

The class diagram now allows you to directly enter your method definitions in the class details pane. Code is generated on the fly in the code window. I’m not sure if this is new, but I can’t recall seeing anything like this in 2005.

While you’re editing the properties of your methods, you can also directly edit the code commentary as well. Now there’s no excuse…

There is a new feature allowing you to search for web services defined in other projects, to insert them as web references in the current project. Great productivity feature for distributed applications.

The class view pane gets a new search box that allows you to search for classes fields and properties. This is really useful, and can save programmers hours of hunting on large projects. (provided they haven’t got R# of course)

Yes! LINQ intellisense. Nuff said.

Orcas also introduces a nice Export template feature that allows you to develop a project or group of classes for exporting as a new item template. This feature is a great way to allow architects to ease the development cycle. They can produce pieces of reference code and distribute them to the rest of their development team.

Just select the classes that you want to export.

Give an explanation of what they are intended to do.

And visual studio goes through them creating placeholders for class and namespace identifiers. These can then be filled in when the developer creates a new item.

there are still problems that need to be sorted out though. Like project properties…

These are a few of the things that I noticed immediately. I’m sure there are more to come. The documentation has not been overhawled much, and the LINQ section is still mostly empty pages. But my initial impression is that Orcas is going to be a delight to work with, for the whole team.