I had the opportunity to assist one of my co-workers today in troubleshooting a web service + Silverlight client I had built for a customer a while back. The combination of the two enables users to upload large files to a server over intermittent internet connections. My co-worker mentioned that she got an error message in a message box from the Silverlight client stating that something was wrong with the parameters sent to it.

In the end it turns out that the parameter for the maximum file size allowed to upload had been set to 3 GB. The specification I received when building this stated that the maximum file size that the system should be able to handle would not exceed 1 GB. So I figured a regular int would suffice for managing the maximum file size restriction.

So what this malconfiguration gave was that the Silverlight client tried to stuff the value of 3GB into an int – this is a no go. My co-worker is not to blame for this, she just got this particular setup handed to her from someone else.

What you specify is what you get.

The past couple of months I’ve had reason (more than usual) to sit back and think about all the different frameworks and patterns available out there. One specific example of this is the following:

Imagine that you would want to build a web service whose role it is to impersonate a SharePoint list. This list is then supposed to be consumed by an Outlook clients calendar tool. The data you want to fill this calendar with is stored in a database containing approximately two tables. The reason I got in touch with this was that I was asked to solve some problems regarding the switch from regular time to daylight savings time and calendar items tagged as all day events. Upon hearing about this existing system I thought something along the lines of “How hard could this be? It’s just a bunch of tables and a web service contract to fulfill.”. Well, as it turns out – the joke’s on me.

I’m not kidding when I say that the code base in the repository for this project consists of ~200 files! Factories, Repositories, Providers, Containers and god knows what! When you open a project and within the time frame of about five minutes can’t figure out where approximately to begin solving a specific problem there has to be a problem with how the code is organized. And I don’t see myself as an under qualified developer. What I ended up doing was setting a breakpoint in Global.asax at the start of a request and then step my way from there. And the funny thing is that all the database access code was hand written. NHibernate (or any other OR-mapper for that matter) hadn’t crossed the mind of the previous developer (or at least wasn’t implemented).

Grossly over engineered. That’s what comes to mind when I look back at this.

A couple of days ago I was recommended the following article: Joel On Software – Why I hate frameworks. Read it! It’s quite a funny read and I can definitely relate to this problem. I also think that this specific issue should be more widely discussed. Somehow it seems that the software development world has moved away from solving real problems to solving problems related to the problem solving. Not quite sure how that adds immediate value for the customer. Also not quite sure how it relates to working agile. If we extrapolate the current situation just a liiittle bit more we’d end up with architects and developers adding a bunch of frameworks to their project and organizing them according to some new patterns (which are bound to appear) they’ll expect the code to write itself!

And I haven’t even mentioned the frameworks managing the other frameworks.