Abstraction and Naming

I was recently reminded of how I tend to abstract software (one of the reasons I'm an architect).  I was discussing the high level architecture of a product with a client.  We had a sketch on the white board of the various components in the solution and how they interacted.  After I repeatedly spoke of one of these components as the "DOC engine" several times, my colleagues corrected me and told me it should be the "OOC Engine".  Practically the next words out of my mouth were to call that component the "DOC Engine" again.   As I said it again I finally saw the label on the whiteboard that looked like"DOC Engine", which is why I had been repeating it.

At that high level of conversation, the actual words I used to talk about the component were actually rather arbitrary, which is why "DOC Engine" worked just as well for me as "OOC engine".  For that matter "Fred", "Foo" or "Fidazzle" would have worked just as well for me.   It was just a software component with some responsibilities and interactions with other components.  The name was irrelevant.

However, as design advances, names become important.   In one of the earliest projects I worked on as an independent consultant, the developer I was working with named a table "Transmis.dbf" (yes that's a dBASE file name, and yes, it's eight characters).  He called the file "Transmis.dbf" because it contained the set of data that needed to be transmitted for orders.  The file was actually an order detail file; it had one row for every item entered on an order.  I worked for years with that code and every time I had to use the "Transmis.dbf" file I had to do a mental translation between order detail and "Transmis".  Or when I looked for the order detail table and couldn't find it, I eventually remembered it was "Transmis".  Every time.  For years.

So, I do believe that picking the right name is critical and will either help or hinder developers in understanding your system.  But like anything, there's a time to pick the name and it doesn't have to be at the outset.  The right name is a result of understanding the responsibilities of a component, and until you've crisply defined those responsibilities, almost any name will do.  Feel free to use "Fidazzle".

An example of why Microsoft sometimes drives me crazy

One of the nice things added in .NET 3.5 is the ability to use the ASP.NET membership providers from Windows form and WPF applications, also known as Client Application Services.  It's a great concept that I'm looking at for a project I'm working on.

One key piece of implementing authentication is the ClientFormsAuthenticationMembershipProvider class (yea, it's a mouthful) which provides the client side membership provider function and is a subclass of MembershipProvider.  So far, so good.

Check out this screen shot from the members for the ClientFormsAuthenticationMembershipProvider class:

Notice anything interesting? Like almost all of the properties say they're not used in this class? If you look at the methods, you'll see pretty much the same thing.

This is terrible object oriented design.  This class inherits from a class when it only implements a very small subset of the methods and properties of the base class.   This class design makes me think there are at least two separate coherent classes at play here (one for "client-side membership providers" and one for "server-side membership providers") which should be separate classes composed into a "membership provider".  Or they could have created a parent class of the existing MembershipProvider with the appropriate properties and methods for a "client-side membership provider".  Or what's more likely is that there are several coherent classes hidden here, but frankly I don't want to think about it any more.

I appreciate the fact that they've added the great ability to use the MembershipProvider from Windows form applications.  I just wish they would have done it in a way that doesn't turn my stomach.

Eggs

My wife scrambled eggs this morning.  When she finished, she left the pan and plastic fork  on the stove.  She used a three tine plastic fork.  It's annoying how the egg hardens on the tines and becomes a pain to remove.  

When I scramble eggs, I like to give whatever utensil I use a quick rinse immediately after I'm done.  In general, when I cook, I like to rinse things as I go along, because I know it will make cleaning much easier.

As I was trying to remove the egg from that fork today, I was thinking about software development  and how often we do the same thing.  Instead of taking care of problems when they're small and it would be easy, we ignore them because we're in a hurry.  We let the little problems grow into cruft.  We let cruft grow into design debt.   We end up with  applications that cause terror when our customers need them to change.

So I  need to ask, can we all just rinse the fork?

Firebird and the .NET Membership Provider

I've started working on a project with the Firebird database server which is an open source product created from Borland InterBase.   My first impressions of Firebird are positive.  It was easy to install and get working.  I downloaded the personal edition of IBExpert, which is an excellent GUI administrative tool and does several things I wish that Microsoft tools did.  And since there's  a .NET data provider for Firebird, talking to it from my C# code was pretty straightforward.

The surprising thing is there in addition to providing basic data access, the .NET data provider also has an implementation of the ASP.NET Membership Provider (and the role and profile providers).  I thought that was pretty cool.  Until I tried to use it.  It's not that it doesn't work.  It just doesn't behave like I think it should.  I was able to get everything wired up on my ASP.NET site by looking at the excellent article here.  And once I figured out that the user name was case sensitive, everything worked like a charm. 

By case sensitive, I mean if the data in the column is 'joe' and you do a SELECT * FROM Users WHERE Name = 'Joe', it will not return the data for 'joe'.  Not what I expect coming from a Microsoft SQL server background. 

Doing a little more investigation of Firebird, it quickly became apparent that it is inherently case sensitive, given the workarounds that are suggested for doing case insensitive comparisons.  In theory, you could create a case insensitive collation, and there are some out there, but they appear to be out of date, and do not address Unicode, which I am using.  Since I have the code, I could go through the membership provider and change all of the selects to uppercase everything, but that's a fair amount of code.

This whole thing also got me thinking about the design of the Membership provider.  Based on previous experience, I expected the ValidateUser method on the membership provider to take a case sensitive password and case insensitive user name.  However, there's nothing in the definition of the Membership provider class that defines this behavior.  In fact, I bet with the right configuration of Microsoft SQL server, I could see this same case sensitive user name behavior. 

Does this mean that the contract hasn't been specified completely enough?  Probably.  The whole idea of the membership provider, after all, is to allow the implementation to differ without impact to the site.  And that is clearly not being accomplished if one implementation is case sensitive withe respect to user names and another is not.  Just one real world example of why you shouldn't believe it when they tell you you can just switch out providers and everything will work.

Is it worth the effort to design software well?

Martin Fowler just added an article on the DesignStaminaHypothesis to his bliki (a cross between a blog and a wiki) to answer this question.   His hypothesis is that design will slow the initial creation of functionality, but at some point ( the "design payoff line"), you will be able to add new functionality more quickly by leveraging design.  I state this as a hypothesis because he does also.   While it seems perfectly intuitive to any practicing software developer, and most software developers accept it as true, it cannot really be proven since there are so many aspects of software development that are difficult to measure (output, quality, etc.)

I definitely agree with this judgement that the design payoff line is lower than most people think, and that design is critical in creating software that will both work well today and enable changes tomorrow.