Surface Fixing

What is surface fixing? Surface fixing is a phrase I use for a fix, which is implemented in a layer above the layer where it occurs. If we imagine the standart 3-tier architecture and we have a bug in the Data Access Layer, surface fix will be to implement the fix in the Business layer or the Presentation Layer. It is common for junior developers or companies where the things should happen in a matter of hours or days (companies with short deadlines). Example of a surface fixing: Let's say we have a page for registering users (Presentation Layer). On user registration this page creates the User object (Business Layer). Sets its properties as necessary, and calls it's Save() method. The Save() method creates

an instance of the UserDAL object (Data Access Layer) and decides whether the task is to create new user or update existing one. Let's say we will create new user. The User Business Object -> Save() method will probably call something like : UserDAL -> InsertUser(long UserID, string UserLogon ....);

Now let's say that the Data Access Layer doesn't escape the single apostrophe in the UserLogonID. Passing parameter as O'Conner or something like this causes exceptions. The question is where should this be fixed?

I see most of you answering : "In the Data Acess Layer offcourse!". That's the best place but if you are working on a small project.

Now ask yourself what will happen if we fix this in a big enterprise system with hundreds of modules / pages referring to that particular routine? After all the other modules / pages are working they will stop working or at least stop working correctly. With other words - your fix will require the whole system to be redeveloped. And what's worse - the QA team will have a lot of work. They will love you for sure :). And to make the things even worse we will imagine that we are near the deadline (which is almost sure after we are testing already). In such cases the Surface Fixing may help.

Below I am giving the advantages and disadvantages of the Surface Fixing.

Advantages:

Your fix will not broke anything in the existing modules

The fix will only be tested, not the modules which may be affected

Ideal to use near deadlines

Disadvantages:

The fix isn't applied at the right place

Conflicts may appear in the future with modules which are working correctly

Against the official software development standarts

When to use this approach ?

When we are developing module in a big system with lot's of other modules which depend on the bug

When we are near deadline

When we are sure that there will be new version.

Conclusion:

This approach is perfect to fix some bugs in the current version, but consideration to completely fix it in the next versions should be made. It simply is not right to use this approach as a regular fixing guidance. In the software development and the 3 or more tier models the above layes should only see the previous and depend on it. And what's more important - the above layer should get the data as expected.