Justin Lovell's Blog

An Apology to Mark... but also my thoughts

justin — Wed, 29 Jun 2005 07:12:00 GMT

(Note: sorry for this being off-topic but the originating thread started on the main feed and I would like to show a human face)

In this blog post, I think I want to extend a public apology to Mark. The only thing I feel that I owed to him is that I took private correspondence and put it on a public feed. It is a completely disputable if the paraphrases are true but I don’t want to do that because the low down is that I did not seek Mark’s permission.

But before I get responses like “damn right but… that is not all you have to apologize for,” it seems that some of you have missed the point completely on what my objective was. This is not in due regard with the public feedback I received but also the ‘private’ feedback so I’m not targeting any particular group – I’m talking out to the world here. I tried to floor out my logical thoughts here but I’m not guaranteeing that it will sound like that.

My objective was not to go about and lower Mark. I can dissect my blog post word for word and clearly indicate that I was not disrespectful to him (besides what I’ve already apologized for). I was warming up the plate to say that “Mark, I know you are busy till the end of the month but I’m ready so let’s get things moving.”

Granted, I was expecting either of the two of the responses. Either the “Come on Mark, let’s do the deed” or the “Why not organize it yourself?” I did not justify the later in the original text because I just forgot to. However I would like to add something to this aspect and the sincere truth is that I don’t know of anyone personally who can or know of someone who might help me get things rolling. How many Durban SaDeveloper contacts do I personally have? About… one to be precise, and you guessed it correctly, Mark. Now I’m stuck with absolutely no starting point.

Besides, why should I have to go and prepare the presentation and still organize a venue? Do you have any idea how much work it is to prepare either two, especially the later one if there is no real starting off point? Maybe you have; maybe you haven’t but many hands make the workload light… and that is what a community should do, right? It shouldn’t burden one to prepare something and then to organize the venue – everyone should pitch in so that it is an enjoyable experience.

But I don’t think you guys skipped that thought, surely! You guys aren’t that mean, right? Especially after I pointed out that I had no real starting block with contacts. And you really understood me, no? Hmmm… tell me that I’m not too assured by the generosity you kind people have shown me after adding those comments.

But let’s assume you were kind sirs (and madams if the anonymous showed any sex) and you weren’t focused upon the task of trying to rip anything into your advantage. It seems that my light humor was missed completely – I was using it as a “helper” in my intention. It seems that there was no applause or acknowledgement for that in my message. Maybe it was seen out of context humor because there is nothing else that could be possibly wrong with that post that some people will take offense to? It seems like that.

And this is where I have to draw the line out to you – I’m rather confused myself if the humor is in context or whether it is not. How would one define a hard line that it is out of context? The answer doesn’t matter because I use similar humor in my presentation. I don’t want to offend people (although none are targeted at any person). I can’t take that risk. So here’s my dilemma:

I can leave the presentation as is. The difference between the blogging world and in person presentation is that I’m about to annotate my content with a smile, a grin, a shaking head, ect.
I can take out the humor from my presentation. If you want a stupid boring thing to talk about the next day, encourage me. However if you are not the sensitive kind, please let me know if you require the exciting presentation to stay awake.
I can just not present at all and dwindle this down to an article, quite easily. I don’t want to do this. It is only an option because if I do take out the humor (or large chunks), it might look like my presentation has loads of holes. I’m not putting this as an option out of spite.

At this moment in time, I’m not ready as I’m undecided on what I want to do with the current presentation. I am reviewing my presentation to help me make that decision.

Besides, as Stuart said, “I’m sure this one will rock the planet.” Now I’m also having doubts on whether to present at all because I now know someone’s sarcastic thought – something they’ve prejudged before they know anything. Worst case is that this thought is shared amongst others. And that in itself worries me because that can determine if the user group meeting would have a chance to succeed all due a decision made before it had a chance. I’m not the one to give up but this… this… this is more than enough to deter me. The only reason why I think this ‘thought’ is shared amongst others is that there’s no chance that someone will peep out that thought if there was not a crowd entertaining them.

I’ll let you guys know what I decide soon, if you care.

Yet another comment about Interfaces vs. Classes

justin — Mon, 13 Jun 2005 19:07:00 GMT

Mike left a comment last week on one of my blog entries about my ravings of interfaces and classes. First off, yes, you are quite right that explicit declaration of interfaces has its advantages in terms of breaking and bending the rules of polymorphism. It is one thing that I’ve been waiting for someone to mention.

In terms of categorizing a class by saying Person class implements the two interfaces of IPersonDetails and IPersonAddress might sound quite brilliant. But I would like to argue that it’s the learning curve of your own API – you will pay for it, I promise, on medium to very large projects. Now I must remember that the Person class implements the two interfaces explicitly – so I have to “cast” the Person instance to the interfaces. It might sound like an alright situation at 10 main classes but if you can remember which interfaces your classes implement explicitly (without going to the documentation or the definitions because that takes you out of your IDE) for 50+ main classes, then you have one excellent memory. But the problem is that I don’t have a memory like that! Neither does the guy sitting next to me have that.

And besides, when you break down your class structure into interfaces, are you going against the idea of interfaces? Are they ever only going to be implemented by one class? If so, why bother? I hope you catch my drift where I’m coming from, about showing the correct usage of interfaces in the OOP world. This is where I went on saying in the third part stating that interfaces have the tendency to add development time to any project.

And on as a side note, I see that I’m getting quite a bit of Google traffic onto those posts. I think I should just clean them up quite a bit at some time in the future because maybe I’m the next Martin Fowler… well, at least I’m allowed to dream big.

Blog Spam: How to fight back?

justin — Mon, 13 Jun 2005 19:06:00 GMT

Alright, it is about time that these spammers get what they ask for? Our time or their time. It is nice how innovative they have got with the one exploit that I silently observed about four or so months ago where these nice RSS features allows for adding of comments.

But here is an appeal: why don’t we leave the crap on our site? I mean: if they have a huge influx of links, they are going to hurt their own name within eight weeks when Google comes around. However, should Google find the links to these sites, and then not find them the next time round, will think that we had news flashes upon our blogs, which will ultimately lead to them hurting themselves.

I know it sounds stupid but think about it. They have us figured out on what actions we will do and know more or less how Google operates. I know that doing this action will make our blogs, our pride, more “dirty” but eventually, I’m sure they will figure out that this technique is not working for their ranks. I would hate to resolve to this behaviour but other than that, how else can we fight back?

One option is to rewrite some of .Text’s engine ourselves such that any track backs under goes moderation before they are even displayed. And we would receive an email when there is a track back awaiting approval. Should we not approve the content within five or so weeks, the track backs are removed automactically.

I think I like the sounds of the later. Is there any other better ways, besides physically flame-throwing the spammers, that you can think of? And, should I volunteer to look at the code-patch, would it be accepted? I personally don’t know the answer to that but .Text is dead – no more development will occur on it so are we going to be Telligent’s label bitch in the near future (Community Server) or are we going to migrate to dasBlog?

VS.NET 2005 release dates announced

justin — Wed, 08 Jun 2005 06:20:00 GMT

I have just received word from a fellow MVP from the USA, Steven Smith, that the .NET 2.0 product lines has been announced for a release day. This announcement was made by Paul Flessner in his keynote on the second day of TechEd US.

So, save the following date into your Outlook and make that big red ring on the desk calendar – November the 7^th is the week that things will happen. (And yes, the year is 2005 :-P).

The DialyWTF – down the tubes it goes

justin — Sun, 22 May 2005 07:27:00 GMT

About 10 or so months, I removed the much proclaimed site called the TheDailyWTF from my daily RSS tour (www.thedailywtf.com). I’m just going to spring my opinion straight off but I think that the group that partakes in the approximate 200 replies to a post is… well… like a playground.

Bear with me – when the site started, it was a very entertaining, fun one. However, just go and browse to the latest and ‘greatest’ WTF and it is like teasing between children. I take for example the conversation between a junior programmer and a senior programmer where the junior was asking how to increment a number by 11. I don’t know what’s missing here in the humor… is it that a junior was asking the question? If it was the other way around, then yes, go ahead and put it as the WTF.

Whoever is in this crowd thinks too high about themselves. I mean that they are in constant search for a flaw in their chosen victim; it is as though they get obsessed with the hobby and become very big-headed. They also have a tendency of rising to senior positions and shunting the door behind them and never acknowledging anyone “under” them. Even though the new guy might be a bright dude, their potential is never realized by the company and by them personally - all due to fate's timing.

In conclusion, I think these people create a very unpleasant atmosphere, no matter what position you are in relation to them. Do I have any agreements or disagreements? And if the later, please support your argument with good reason.

Getting ASP.NET 1.x running on x64 platforms

justin — Fri, 06 May 2005 19:19:00 GMT

In my blog post about me moving over to a 64-bit operating system, one of the things that I almost shot myself in the foot is that I almost lost my ability to develop for ASP.NET 1.x.

After a few hours reading the IIS 6 kernel (I know the subject quite well now), I came to a conclusion that ASP.NET (in fact, the whole of IIS) did not work was because of the ISAPI library being in a 32-bit native image. That got me thinking that 64-bit images cannot work against 32-bit images and the same with vice-versa.

So I thought to myself that if I can launch IIS 6’s worker process into 32-bit mode, that worker process can call ASP.NET ISAPI filter since both are 32-bit. A quick Google search query on my guess which led to me to these steps.

Open up command prompt.
Change your directory to %systemdrive%\Inetpub\AdminScripts\
Execute the following command:

cscript.exe adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 "true".

And behold: you can have worker processes running in both 32-bit and 64-bit mode.

Urgent: Job position in Durban

justin — Tue, 03 May 2005 19:46:00 GMT

I know I posted this quite some time ago but now the situation is desperate. So desperate, I don’t have the time to blog this during office hours. We have expanded the criteria for our job candidate and if you are looking for work elsewhere in Durban or know of someone who might be interested, from a Junior Developer to a Senior Developer. There is hardly any restriction on your previous working experience.

If you haven’t written any .NET code professionally, that is alright if you have toyed a little with .NET during your spare time. As long as you have some sort of running start to combating .NET projects.

Even if you have sent a CV before, please resend your CV to cv@burton.co.za. My boss (his name is also Justin), will probably ask for you to “submit some source code,” when he really means he expects one class file; not a sample project or anything like the sort. If you want to submit more than one class file, then that is fine. All he is asking for is a sample of something you have not coded in a team collaborative environment – the bottom line is that it must be code that you have written by yourself.

You take the decision of what will be to your advantage: if you feel that a small project will sum it up, great! If you feel that you don’t want to infringe or surrender any intellectual property (including your own ‘private’ work) by trying not to submit “too much,” we respect that. (When they asked for some source code from me, other than my articles, I gave them a small amount of code from multiple projects). Again, the bottom line is that it must be your code.

I’m fully 64-bit Enabled – Finally!

justin — Sun, 01 May 2005 19:00:00 GMT

For those who do not know, I’ve had an AMD64 machine since November 2004. At that moment, there was only a release candidate for the x64 initiative and decided not to run on it because…

I’m not a big fan of beta software.
Virtual PC did not work on the 64-bit operating systems.
I would run the Whidbey bits on virtual machines and since that did not work… I could not make ends meet.
There was lack of documentation that ASP.NET 1.x would run through IIS.

Well, with the news of service pack one for Windows 2003, which also meant the final release of the x64 platforms. Yesterday, I downloaded the ISO for Windows XP x64 from MSDN, burnt the CD and formatted my PC completely forgetting the reasons why I did not install a 64-bit operating system in the first place.

Well, I thought it was fast on a 32-bit operating system – you must certainly see the speed difference now, even when running 32-bit processes.

Now that I got a little settled in, I have noticed a few key differences between the other Windows XP platforms – this is more inline with a Windows 2003 kernel feel. The first difference that I saw is that there are two editions of Internet Explorer – a 32-bit and a 64-bit version as shown in the screenshot.

Here is a blog post from the Internet Explorer team which explains the difference between the two. What I have done to my Internet Explorer is found the Google bar and added it to my 32-bit version so I know which version I’m sitting under.

Everything is 64-bit. When I say everything… anything that comes with Windows. Notepad is 64-bit, Windows Explorer is 64-bit, WordPad is 64-bit, and Remote Desktop is 64-bit and so forth but not Windows Media Player. Unfortunately, that is still stuck on 32-bit… like if that is a “problem!” I think these 32-bit processes work faster than on 32-bit operating systems.

To determine if the process is 32-bit or 64-bit, go into the task manager and if any processes have a “* 32” next to the image name, is running as 32-bits. Here is a screen shot me running as much 32-bit processes as 64-bit processes.

As far as device support goes, it is perfect. I only had to install sound drivers. Everything was setup fine, perfect in fact! I found other installations of Windows XP just too daunting as far as drivers for display, sound and SATA are concerned – even after applying the latest service packs. The only driver that I had to configure and run under 32-bit mode was my sound driver.

Now I’m busy playing some music through Windows Media Player and realize that there is no ability to have that toolbar on the task tray. Damn! Now that is the second thing I found a bit ‘short’ in the 64-bit world. The first thing that I found short was that I forgot that Virtual PC does not work on 64-bit, yet. I only why it can’t work – similar to the Internet Explorer problem of running 64-bit with 32-bit and vice versa and since the task tray is 64-bit and Windows Media Player is 32-bit, it cannot run. However, that is a bit contrary since the Office language bar is running there and that is a 32-bit process.

As for the ASP.NET 1.x running on 64-bit windows, I did manage to get it to work eventually. I did tons of reading and I will post a small (I promise!), separate blog post to create documentation on Google that it is possible – not like what others have claimed it to be. I can’t believe I did not do any research and completely forgot about this part before jumping on the 64-bit operating system.

The biggest pitch of Windows XP x64 feeling like the Windows 2003 kernel; well… it is the 2003 kernel! Here is a screenshot which will explain about everything since this picture is worth more than my 1000 words.

Yes ladies and geeks, it is IIS 6 running on Windows XP… in 64-bit mode. (And yes, I did have some humor naming my machine “8bitsquared”). Wow! Now this is a feature and a bit for all ASP.NET developers. Need I say more? Yes (or no, whichever way you feel) – you can’t define multiple web sites but I do have a trick up my sleeve on doing otherwise. Another thing I’ll leave to another time.

And as far as memory management goes… it is awesome. You can feel that there is substantial difference between the 32-bit and 64-bit model. Back then, I brought this machine at under an $800 price tag – my first machine so I had to buy everything. I would only imagine that prices have gone down and the only thing that is missing from this machine, I feel, is the hitting of that one gigabyte of RAM. I currently have 512MB and I must say that it is serving me much better in the 64-bit world than what it did in the 32-bit world.

Martin Fowler on about Evolutionary Design

justin — Sun, 01 May 2005 17:23:00 GMT

I started googling around to see what links I can put in reference to my previous blog post about the part of refactoring. And it seems that my perception is somewhat similar to Martin Fowler’s. I quote…

Martin Fowler:

Part of the justification of YAGNI is that many of these potential needs end up not being needed, or at least not in the way you'd expect. The effort you'll save by not doing any of them is less than the effort required to refactor into the ones you do actually need.

And then Martin concludes, in the section I linked to…

Martin Fowler:

With any new technique it's natural that its advocates are unsure of its boundary conditions. Most XPers have been told that evolutionary design is impossible for a certain problem, only to discover that it is indeed possible. That conquering of 'impossible' situations leads to a confidence that all such situations can be overcome. Of course you can't make such a generalization, but until the XP community hits the boundaries and fails, we can never be sure where these boundaries lie, and it's right to try and push beyond the potential boundaries that others may see.

In fact… read the entire paper. It is quite interesting.

And as a side note, this is the first time I’m referencing Martin’s work because for the first time, I actually have arrived to a similar methodology to a well known, well respected person, without any input other than my own experience.

Part 3: Interfaces are not worth the classes that they are written on

justin — Sun, 01 May 2005 12:19:00 GMT

Scott Dukes has blogged a response to my two (going onto three) blog posts that interfaces are not worth the classes they are written on. In this third one, I will be responding with a practical example (in other words: physical code) and also add a twist to the end of this blog post.

I must say that I’m in agreement with most part of Scott’s content. Besides some major commentary which I’ll place in this blog post and the minor ones on Scott’s feedback, there is only one aspect which I would like enhance the situation a bit – which will essentially fall upon refactoring technique more than anything.

Scott Dukes:

It also pays to look at why we even have interfaces at all; what is the purpose behind them? In a language that supports multiple inheritance (like C++ or Eiffel), interfaces have diminished value. It makes sense to define behavioral contracts using abstract classes which also provide a generic implementation of the behavior. In these languages multiple inheritance allows you to simply plug in functionality to any class that requires it, rather than having to create explicit implementations of an interface

When I first started with OOP, multiple inheritance was like a wet dream. I always dreamt about, fantasized about it but never had it because C# and VB.NET did not allow it. But as my experience grew, I realized that multiple inheritance upon a class because it has the ability to make contracts vague. Let me just bring another quote before progressing on my point…

Scott Dukes:

In languages that only support single inheritance (like C# and Java), or only interface inheritance (like VB6 - yuck!), Interfaces take on a much more important role. Using interfaces together with object composition allows the developer a similar ability to simply plug in functionality, giving some of the flexibility of multiple inheritance, whilst ensuring that the object models are kept (relatively) simple.

This was commented upon by Peter Munnings of which he stated…

Peter Munnings:

Well explained. I like the nice simple “is a” vs. “behaves as.” I also like the way you explain that a child class gets everything from the base class whereas an interface normally only describes a part of a class.

With VB classic and everything aside, interfaces are the only way for VB classic to define global contracts. So I VB classic is an exception because it is the only mechanism of which VB can go about doing such a thing.

Some people see the interfaces the same as multiple inheritance. Again, I feel that both of these are bounded by a general rule of mine that interfaces (and the second class it inherits and so forth) should be there to define utility operations or small enhancements over the major contract the class carries. With interfaces and multiple inheritance, the chances of a class carrying two or more major contracts is quite possible.

At this point, I would have to commend to Scott when he summarized everything by saying that the abstract base class vs. interface approach is OOP technique (and etiquette).

Scott Dukes:

Ultimately it boils down to OOP fundamentals; it's generally a good heuristic (rule of thumb) to keep your class interface as small and cohesive as possible. The biggest risk in using Base Classes comes from the tendency to move unrelated behavior into the base class, as the implementations evolve, resulting in a less cohesive "interface". And what’s more, it is easy to do. Sure, you run the same risk using interfaces, but it's not nearly as convenient for the developer, so it's much less likely to occur.

Yes, it is more convenient for the developer as I’ve also stated in my argument in regards to the evolution of the base class. Maybe, it is too tempting like the serpent selling the apple of knowledge to Eve. However, it comes down to how “strict” the developer is on oneself: if the developer just cares about punting code out, he will fall in the above mentioned trap of the base classes. In fact, if he cared so much about just outputting code, he would do the same thing to interfaces. At the end of the day, these people are just cared about how many lines of code they wrote.

On the other end of scale, you will get well disciplined developers who will not try to shortcut anything and try keeping the design “right.” These guys are more concerned how many feature-sets they have outputted and how much of the work they have removed from the road ahead.

And (the twist starts here…) in between the two styles of people, you have the general population who always try and design for something much unknown which could happen, even if it has the slightest chance. I will resume this point after my practical example upon Scott’s example.

Scott Dukes:

I said earlier that interfaces provide a common abstraction to handle completely disparate implementations. This enables us to create methods that will handle any implementation, same or different.

(Code snipped out)

You could argue that a base class would provide the same flexibility, and you'd be right, for now. The advantage of using an interface comes in the future. Let us suppose that in the previous example we had created a base class called BusinessEntity containing common functionality; we could then have defined the above method as follows.

(Code snipped out)

However, what if six months later we have a requirement that Employee needs to support remoting and consequently needs to extend MarshalByRefObject. Now depending on how we've implemented our base class this might be very difficult to do (without affecting the other classes). If we do affect the other classes, by making the change on the base class, there might be repercussions (errors) down the line. Basically it introduces a potentially unknown variable into the equation. By using an interface we can create a completely divergent implementation without affecting any other classes. This is concept is known as the principle of orthogonally.

Let’s enhance the image of example by saying that the system’s specification dictated that everything was to be “internal.” By developing the system, you followed Scott’s rule of thumb of…

Scott Dukes:

I would say that, as a general rule, if the consumers of your class are internal to your system it is safe to use base classes and refactor to interfaces as your design evolves.

Now we have a dead-lock in our arguments. And now we have a contradiction on how the system was designed six months prior and to the rule of thumb.

[Edit for clarification: It is quite ironic that these two statements contradict each other but I’m in complete agreement with both of them. It is true one can easily get away with base classes in “internal systems.” It is also true that refactoring to interfaces will give the most flexibility; especially, if the future of the software is unknown… read further about “volatile future.”]

But I refuse to just void Scott’s argument because this is precisely what happens in the real world [Edit: in other words, I do take merit of his argument and I do agree with him. I would like to elaborate why I feel that although these two statements contradict each other at face value, I would like to discuss the evolution process] – we may design the system in one context, ship the first version. A little while later, we ship the next minor version… both of them focused on small implementation guides – it was a simple structural n-tiered project.

Here comes along management and they want an application-server because they want a nation-wide system and this will ultimately introduce physical n-tiers. We never catered for this movement in the first place because if we put in the slightest hint of this, we might as well have gone all the way. We would have been fighting the dead-line harder because of more code and more testing. And yet again, management wanted little funding as possible because they weren’t too sure if the product would take off… and they weren’t sure on what features were expected in the next major release because this is a new market. So in essence, they wanted version one to ship out the door as fast as possible for obvious reasons.

One might have used the hybrid approach that Scott and I spoke about (interfaces and base classes) but that is also heavy maintenance because that is two contracts you have to update if the other changes. So you went abstract base classes all the way. But I protest! Now we have the need to define an interface and since we have reached version one, what are the chances of the contracts changing in future? Going with base classes and then refactoring to a hybrid approach is very possible. Here is the original code, before refactoring.

Public MustInherit Class Person

Public MustOverride Property FirstName() As String

Public MustOverride Property LastName() As String

Public MustOverride Sub Animate(ByVal animation As AnimationType)

Protected Sub New()

MyBase.New()

End Sub

End Class

Now to refactor to the hybrid approach…

Public Interface IPerson

Property FirstName() As String

Property LastName() As String

Sub Animate(ByVal animation As AnimationType)

End Interface

Public MustInherit Class Person

Implements IPerson

Public MustOverride Property FirstName() As String Implements IPerson.FirstName

Public MustOverride Property LastName() As String Implements IPerson.LastName

Public MustOverride Sub Animate(ByVal animation As AnimationType) Implements IPerson.Animate

Protected Sub New()

MyBase.New()

End Sub

End Class

Maybe this is what Scott was trying to say when he said, “… refactor to interfaces as your design evolves.” With the new refactoring, that does not mean you need to go change all other code which references to Person instead of IPerson.

The reason for this is that 90% of the code you have already written to the Person abstract class is in fact, going to be kept internal. For example, a hyper-theoretical command called MakeEmployeeRunCommand (I must admit, a really stupid example… and name!) is executed from Employee class (which inherits from Person), with the AnimationType enumeration, it can look for the “Run” value from the object and call that internal command.

And in any case of the client code making calls to behavioral classes/structures (command classes for example) from the client side, making the client an “internal client.” The chances of this client being deployed at the other side of the physical tier (becoming a “public client”) are 50/50; there is still that chance that you might not even have to reference to the interface over the base class. And if you have to reference that interface because of remoting, it does not matter – you would still have to ‘touch’ that code to remote it; making the impact of refactoring to interfaces much softer than it sounds.

Refactoring is another topic altogether. It is directly related to the subject at hand, but we will save this up for a follow up. However, I mentioned it to make the point that we can have class hierarchy with all of these definitions all we can have one which is the bare minimum yet does the job… which loops me to the point where I left off about the “vast majority” of developers; and the opportunity to add another direction where the discussion may end up to.

Most of the developers expect anything and everything to be thrown at the system they are designing. Although their system that they are designing is simple and straight-forward, you will find that these guys have the tendency to over complicate something for a very volatile future. Let’s face it: software has a very volatile future. The software might die… it might move to new heights… we never know and the question of “what if…” is always asked.

In my experience, when a specification is written and given to me, I design the system to best suite that specification and the most logical future that the software will have, if any (I’ve just finished one project which has been set with: only one version of the application will be released – a write once, throw away one). [Edit for elaboration: These specifications normally dictate on what functionality is required in the application. I see, where I feel fit, on how to structure on what is “internal” and what is “external”]. I do however, practice caution when designing it initially that I don’t code myself into a “corner” too quickly. The “what if…” question(s) exists because the vast majority of the developers feel that they can avoid the corner. The truth of the fact is that you will always code yourself to a corner eventually and the ultimate trick is controlling how fast you travel into that corner. If anyone doesn’t believe me, allow me to list some examples.

You have coded your application in VB Classic. The tools that you used, you used… and you have coded yourself into the corner by selecting the programming language five years ago – if you coded with C++, you could be using .NET tools today.
If Microsoft decided today that their Office suite is going to be thin client over the web browser, they cannot do it because the thick client offers more features than the web can offer – simply due to the fact that the thick client is programmed against Win32 functions.
Web services were a big evolution to SOA. Some systems have used it extensively. However, little did they know when they started with web services as their SOA protocol, did they find out Microsoft’s interest was in Indigo and web services will eventually fall off the face of the Microsoft world. Now they have coded themselves into a corner.

Read this blog post again. You will then find out that my series’ title of “interfaces are not worth the classes they are written on” with two different hidden caveats:

Interfaces can easily add overhead to the development time.
People, in general, use interfaces and argues that they have not coded themselves into a corner when they don’t even know the definite future of the software they are writing.

Scott, Peter and anyone who is interested: why not take this to The Server Side?