A great many years ago, when I was fresh out of school and learning to be a salesman, we had a sales manager who proudly advertised that his office door was "always open". What he meant, obviously, was that we could drop in any time with questions, problems, and for advice on any sales-related issue that might arise. Forgotten what step five of "the seven steps to making a sale" is? Having problems framing your "double-positive questions"? Struggling to find "a response to overcome an objection"? Just sail in through that ever-open door and fire away. Except that the only response you ever got from him was "...you can always rely on one end of a swimming pool".

Now, I was young and a bit damp behind the ears in those days - and probably not the sharpest knife in the box. So it was several months before I finally plucked up the courage to ask one of the older and more experienced members of our team what he actually meant. "Simple", said my wise colleague, "he means that you can always depend on a 'depend' (i.e. deep end). In other words, no matter what the question or situation, you can usually get the upper hand by prevaricating".

I guess you only need to watch politicians on TV to understand that they all take advantage of this rule. But, strangely enough (and I don't want to give too many precious retailing secrets away here), it can be remarkably useful. Imagine the scene: your customer can't make up their mind about some particular type of plant food (OK, so I was working in the horticultural trade in those days). They ask "Will it be safe to use on my prize Dahlias?" You answer "Well I was talking to a chap last week who managed to grow double his usual crop of tomatoes!" Notice that I didn't say he was using any product he might have purchased from me, or that he actually used any fertilizer at all. Such is the power of vagueness...

All I need do now is overcome the objection, and toss in a double-positive question: "I'm sure that the quality and the results you'll get will be far more important to you than the exceptionally low price we're offering it at this week", and "Shall I wrap it up for you to take away, or would you like us to deliver it tomorrow morning?" Amazing - seems I haven't lost the touch.

So, having regaled you with rambling reminiscences for the last ten minutes, I probably need to try and drift back on-topic. Or, at least, to within striking distance. What prompted all this was reading the preface to our new Microsoft Application Architecture Guide 2nd Edition. In it, David Hill explains that you can always tell an architect because their answer to any question is invariably "it depends". He doesn't say if this behavior extends to things like "Can I get you a coffee?" or "Would you like a salary raise?", but I'll assume he is generally referring to architectural design topics.

And, even though I'm not an architect (INAA?), I can see what he means. In the section on validation, for example, it quite clearly states that you should always validate input received from users. Makes a lot of sense. But what about if you have a layered application and you want to pass the data back from the presentation layer to the business layer or data layer? Should you validate it at the layer boundary? Well, it depends on whether you trust the presentation layer. You do? Well it also depends on whether any other applications will reuse the business layer. Ever. And it depends if you have a domain model, and if the entities contain their own validation code. And then it starts to talk about how you do the validation, depending on what you are validating and the rules you want to apply.

You see, I thought at the start of this project that I could just learn the contents of the guide and instantly become "a proper architect". It's not likely to happen. What it does show is that, yes, you need to know the process, the important factors, and techniques that will help you to perform analysis and make good decisions about structure and design. And you need to understand about conflicting requirements, quality attributes, and crosscutting concerns. You have to understand the types of applications, and their individual advantages and liabilities. In fact, there is an almost endless stream of things that you could learn to help you "do architecture".

And that, it seems, is where the guide really comes into its own. It explains the process and the important elements of design. It lists the vital requirements, and provides guidelines to help you make decisions. It tells you what to look for, where to look, and where to find out more. It even contains detailed references to things like components, layers, tiers, technologies, and design patterns (see http://msdn.microsoft.com/en-gb/library/dd673617.aspx).

And, at almost every step, it proudly flaunts its "it depends" approach. Architecture is not, it seems, about learning rules. It's learning about software and applications, environments and infrastructure, requirements and conflicts, people and processes, techniques and technologies, and - best of all - having your say in how a small part of our technological world behaves. So, come on in - the water's lovely...

Suddenly, here at chez Derbyshire, it's 1996 again all over again. Instead of spending my days creating electronic guidance and online documentation in its wealth of different formats and styles, I'm back to writing real books. Ones that will be printed on paper and may even have unflattering photos of me on the back. And there'll be professional people doing the layout and creating the schematics. It's almost like I've got a real job again. I'll be able to do that "move all your books to the front of the shelf" thing in all the book stores I visit, and look imploringly at people at conferences hoping they'll ask me to sign their copy.

The reason is that we're producing a range (the actual number depends on how fast I can write) of books about the forthcoming version of Enterprise Library. I've been tasked with creating books that help people get to know EntLib and Unity, and get started using them in their architectural designs and application implementations. So the list of requirements includes making the books easy and enjoyable to read, simple enough to guide new users into understanding the basic features and their usage, deep enough to satisfy "average" developers who want to know more and learn best practices, and comprehensive enough to cover all of the major features that take over 1000 pages to describe in the online documentation.

They say that a job's not worth doing if it doesn't offer a challenge, so I guess this job is definitely on the "worth doing" list. And getting it all into books of about 250 pages will certainly be interesting as well as challenging. Maybe I can write very small, or use "txt speak". Need help using the Message Queuing feature of the Logging block? How about: "2 cre8 a msg q u use mmc & put name in cfg file thn cre8 logentry & snd. 2 c if it wrkd look in q". I can see my editor and proofreader having no end of fun with that approach.

But the hardest bit was actually deciding how (and whether) to provide sample code. Its likely there won't be room to print complete listings of all the code I use, which is probably an advantage in that readers can see and concentrate on the actual bits that are important. Of course, I need to build some examples to make sure what I'm writing actually does do what it's supposed to. So it seems sensible to offer the code to readers as well, like they do with most other programming books. But how should I present the code? As a pretty application with nice graphics and a delectable user interface? Maybe be all up to date by using WPF?

I remember when I first started writing books about "Active Server Pages" how we had no end of problems creating sample code that users could easily install and run. There was no SQL Server Express with its auto-attach databases mechanism, no built-in Web Server in Visual InterDev (this was the days before Visual Studio as we know it now), and you couldn't even assume that users had a permanent Internet connection (the vast majority were on a dial-up connection). So you had to create complicated sets of scripts and a setup routine, even for ASP samples, that registered the components you needed and populated the database, as well as providing a long list of prerequisites.

But things are much easier now. You can give people a zip file that they can just unzip and run. Even Windows Forms and WPF samples just work "out of the box". So, even though I haven't done much with WPF before, I thought I'd give it a try. I was doing OK with creating the form and adding some text and buttons, but then it came to adding a DataGrid. I thought maybe they'd forgotten to include it in the version of Visual Studio I'm using, but it seems that I wasn't prepared for the Wonderfully Perverse Features of WPF where you need to use Grids and ListViews and tons of stuff inside each one, then fight with Data Contexts and Binding Paths.

In ASP.NET I just grab a GridView and drop it onto the page. So should I do the samples as an ASP.NET application? That adds complexity with postbacks and maintaining state, and makes it hard to show some features such as asynchronous data access or cache scavenging. And it hides the real functionality that I want to show. Besides which, EntLib is really a library for helping you manage your crosscutting concerns, not a development environment for Web sites. How about Silverlight? Well, then I'm faced with a combination of the issues from WPF and ASP.NET. Maybe I should just take the easy way out and use Windows Forms. As a technology, I know it well and it provides all the features I need to create glorious user interfaces.

And then I remembered how long I've been writing code. Back in the early 80's, an attractive and intuitive user interface was one where you had a text menu on an 80 characters by 26 lines screen, and you could press any key you liked as long as it was one of those in the list. No need to mess about with sissy things like mice or trackballs, and no confusion about which things to click or where to wave your mouse pointer to see what things did. You knew where you were with applications in those days. And there's plenty of interest now in the old stuff such as text-based adventures and simple chunky graphic games like Asteroids and Space Invaders.

So why not follow the trend? Simple example applications that run in a Console window, have simple menus to select the specific sample you want to run, and use simple code to display progress and the results of the process. No need to run Visual Studio, the database will auto-attach to SQL Server Express, and readers can easily find the appropriate code in a single "Program" file if they want to read it all. In fact, I've seen this approach used by the guys from the data team here at Microsoft when they do presentations, and it really does seem to make it easier to see what's going on.

So that's where I'm going at the moment, at least until somebody else makes an alternative "executive decision" further down the line. What do you reckon? Do you want fancy interfaces for your code samples? Or are simple Console applications that focus on the "working parts" more useful and easier to understand? How about this for a flash-back to the past:

Oh well, back to work, holidays over for another year. At least I managed to morph from a sickly shade of pale to a faint shade of tan, and without catching airplane 'flu or any other weird tropical disease (at least not one that's shown up so far). In fact, it was one of the most hassle-free and relaxing holidays we've had. I even managed to forego the doubtful pleasure of email for a whole six days without caving in and searching for an Internet cafe.

Mind you, arriving home and deciding I should try to catch up with the mountain of emails that arrived while I was away was an interesting experience. It seems that my mailbox was upgraded to Exchange Server 2010 while I was away. While it doesn't affect using Outlook over HTTP, I'm battling vainly against the new version of Outlook Web Access. It seems to rummage around and collect every email it can find that vaguely corresponds to the one I'm trying to read, and then hides them all away in a tree view that you have to double-click to see the actual messages.

I suppose it's useful having all of the related messages collected together, even if it includes ones I sent, and even ones I've deleted (helpfully shown crossed out in the tree view). But I reckon it's going to take me a good while to get used to this approach. I spent the first ten minutes trying to figure out how to delete a collection of different emails - it seems like you can't just highlight them all and press delete any more.

And I can't find any options to go back to the old way either - in fact it took ages to find the option where I could turn off Out of Office Replies (which are now called "Tell people you're on vacation"). Maybe I'll just leave them turned on for good so I don't have to fight with OWA very often. Or just do what I ended up doing the evening when we got home and I was too tired to try and understand the new approach - use the cut-down "OWA Light" version instead. It's much like Hotmail (sorry, Windows Live Mail) - it just works like you'd expect.

Aha! (added later) I just found out you need click the little arrow next to "Arrange by" and uncheck "Conversation".

Anyway, getting back to last week's trip, I still haven't figured why it all went so smoothly compared to the usual hassle of traveling anywhere by plane. Yes, we did have to set off for the airport at 3:00 AM; but it's nearby, parking close to the terminal was easy, the check-in queue consisted of two people, there was time for a leisurely coffee, and then through security in less than ten minutes. Half an hour in departures chatting to people we know who happened to be on the same flight, then in the air fifteen minutes ahead (!) of schedule and arrival in Malta half an hour early.

With our taxi waiting at the airport, we were at the hotel within half an hour and ready to hit the beach! And it was just as easy coming home. Meanwhile, Malta is easy because they have real 250 volt electricity with UK-style sockets, and they drive on the proper side of the road (the left). Plus, all of the roads have meaningful road signs, even if every road you go down seems to take you back to the capital Valletta. Although the concept of giving way to others, even when they have priority, is more an option than a rule. I liked that all the roundabouts have a sign saying "Please obey the roundabout rules". I guess everyone does, in a roundabout way.

We did borrow a sat-nav with the rental car, and I'm really glad I didn't buy one like it. The helpful lady inside it had a habit of reading out the directions one turn early, then suddenly screaming "Turn left, turn left, turn left" just after you passed the junction (even when you should have turned right). I think the one word we heard most over the whole week was "Recalculating". Of course, it didn't help that the paper map of the island we were using to decide where to go contained English place names, while the sat-nav only had the Maltese equivalents. She even directed us up one street that started out about a foot wider that the car and then got even narrower, culminating in a right-angle turn. I got a lot of reversing practice during the week.

But if you are looking for somewhere relatively peaceful, pleasant, and full of history, Malta is worth a visit. Go in Spring or Autumn unless you like being burned alive, and - if you don't fancy driving - use the hop-on hop-off tour buses to see the sights. There are some lovely beaches, fabulous views, wonderful cathedrals and churches, a Roman villa, and an amazing walled city (Mdina) to see. It is a bit barren in places, and not the tidiest or best-maintained place I've ever been, but - hey - this is the Mediterranean. And everyone, everywhere, speaks good English. Here's some photos:

And, yes, I did find the house where I lived more than 40 years ago and even got to talk to the daughter of the guy who owned it back then! Meanwhile, I suspect we'll never be able to go on holiday again because it will never be this easy in future.

There's a well known saying that goes something like "Please engage brain before shifting mouth into gear". And another that says "If you can't stand the heat, get out of the kitchen". Yet, after what's now more than a year as a fulltime 'Softie, I've managed to avoid being flamed for any of my weekly diatribes; and neither has anybody pointed out (at least within earshot) how stupid I am. So I suppose it's time to remedy that situation. This week I'm going to throw caution to the winds and trample wildly across the green and pleasant pastures of generics, and all without a safety net.

OK, I'll admit that it's probably not going to be a hugely technical venture, so if you are expecting to see lots of indecipherable code and complex derivations of generic functionality, you're likely to be disappointed. You might as well get your email client warmed up now ready to fire off some nicely toasted opinions. I mean, it's not like I actually know much about generic programming anyway. No, where I'm going with this is more slanted towards the requirements of my daily tasks - the terminology.

You see, I'm of the opinion that when I write technical documents, they should be comprehensive enough to ensure that readers can follow the topic without having to dive off and consult an encyclopedia or dictionary every five minutes. While I don't want to reduce it to the "grandmother sucking eggs" level, which would just be boring to average developers and probably excruciatingly useless to the really clever people out there, I do need to make it reasonably comprehensive and self-sufficient. I mean, I really hate it when I'm reading something and have to keep stopping and re-reading bits to try and figure out exactly what the writer actually meant.

You've probably been through this process, where you come across what seems like a simple word but the meaning in the current context is not familiar. The person who wrote it probably knows the topic inside out, and so the meaning is obvious to them. Yet not grasping what it really indicates in terms of the surrounding text can make the rest of the article pretty much meaningless. You need to know the topic before you can understand the bits that will help you to learn about it. Like: "Ensure you check the reverse osmosis defractor for discompulation before remounting the encapsulator". Does that mean you need to buy a new one if it's gone rusty? Who knows...

Anyway, getting back to generics, I recently seem to have stirred up a discussion about the meaning of three fairly ordinary words without really trying. In fact, I suspect I've put our current project back by a week as all of the brains-the-size-of-a-planet people on the dev team try and figure out exactly which words mean what, and how we should use them. So what are these three amazingly complicated and unfathomable words? Would you believe "unbound", "open", and "closed". In fact, you can throw in "constructed" as well if you like.

Constructed generic type: A generic type whose generic type parameters have been specified. A constructed type or method can be an open generic type if some of its type arguments are type parameters of enclosing types or methods; or a closed generic type if all of its type arguments are real types.

Open generic type: A constructed generic type in which one or more of the generic type arguments substituted for its generic type parameters is a type parameter of an enclosing generic type or method. Open generic types cannot be instantiated.

Closed generic type: A constructed generic type that has no unspecified generic type parameters, either of its own of or any enclosing types or methods. Closed generic types can be instantiated.

It seems that most folks agree that a generic type can be unbound or constructed, and a constructed type can be open or closed. Microsoft seem a little shy about defining what an unbound generic type is, though in the Generics FAQ they mention that "the typeof operator can operate on unbound generic types (generic types that do not yet have specific type arguments)". And there are plenty of definitions elsewhere that firmly identify it as being a generic type where the types of the type parameters are not defined.

Meanwhile, it seems like most people also agree on what a "closed" type is, so the main issue is: what's the difference between an "unbound" and an "open" generic type. If an open type is also a "constructed" type, does that mean that it has the type arguments actually populated - even though the code that's executing to achieve this only contains the placeholders? Or does "constructed" in the realm of generics mean something other than the more usual "built" or "assembled"? Does a generic type start out as "unbound" and then, as it becomes "constructed", does it move through "open" to "closed"?

Perhaps there is a nanosecond or two, as the electrons fight their way through the layers of silicon in the CPU constructing and closing the type, that it's no longer unbound, but not quite closed yet? Smacks of Heisenberg's Theory of Uncertainty and Schrodinger's cat if you ask me. Maybe it's all wrapped up in particle and wave theory. Or could it be that unbound types don't actually exist at all? Maybe, as they aren't actually instantiated "things", they only exist in an ethereal context; or they only exist when you aren't looking at them. I suppose that, as the only thing you can instantiate is a closed type, we don't actually need to worry about the other types anyway.

Trouble is, when working with a dependency injection mechanism (like what I'm doing now, as Ernie Wise would have said) you need to discuss registering types and type mappings for generic types that do not have all of the type arguments fully defined as concrete types. So we're trying to decide if these registrations are for "unbound" types or "open" types. When you define a registration or mapping in a configuration file, you use the .NET Framework type name without specifying the type parameters or type arguments; for example MyApps.MyTypes.MyGenericType`2 (where the "back-tick" and number define the number of type parameters in the type). When you use code to perform the registration, you also omit the type parameters; for example RegisterType(typeof(MyTypes.IMyInterface<,>)). As you saw earlier, Microsoft says that "the typeof operator can operate on unbound generic types (generic types that do not yet have specific type arguments)", and these sure look like they don't yet have specific type arguments.

But could these registrations really be "open" rather than "unbound"? All the definitions of "open" talk about the types of the type arguments being provided by "an enclosing generic type or method". When I'm just creating a type registration, how can the type parameters be populated from an enclosing type? If I'm registering the generic child of a parent type, I can't specify what (who?) the parent will be. If I'm registering the parent, I can't prevent somebody adding a class that has a different child. And I can't register a method at all. So there is no way I can specify where the type arguments will come from.

The problem is that almost everything else I read about using dependency injection mechanisms talks about only "open" and "closed" types. It's like "unbound" types are unclean, or unattractive, or maybe just not worthy of use in a shiny new container. Perhaps it's a conspiracy, and we'll discover that NASA actually buried them all in the Nevada desert so they can't be used to confuse clever programmers. And if I talk about unbound type registrations in my documentation, will people just make those "phhhhh" noises and toss it aside with a comment such as "...obviously doesn't have any idea what he's talking about...", "...waste of time reading that...", and "...who let him out again...?"