Coding Insomnia

I just came back from a seminar on Web Service Software Factory (hereby referenced as WSSF), and I just cannot resit the urge to share my feelings on the subject.

The presenter introduced WSSF as the solution to a lot of problems; Straggly Code Base since each dev/architect has his/her own way of building a service, Varying Quality Levels depending on who did what and Bad Productivity caused by lack of re-use of both code and knowledge. Let’s see (from my point of view) what the current version of WSSF offers when it comes to reducing these problems. Now, this is going to look very critical and you might even think that I don’t appreciate the efforts of the PAG team. I assure you that I do. I’m just saying that the Service Factory as it is today doesn’t live up to the promises this particular presenter made.

Straggly Code Base*

I think this is a serious problem with very few (if any) good solutions, and the WSSF in its current state certainly isn’t one of them. The underlying problem is, of course, that our development platforms constantly evolve (to the better). This means that every time we start building a new service there will be some new feature, technology, utility class library or toolkit that we really should take advantage of in order to build a better service quicker. The WSSF is simply one of these. Since its built by the PAG-team, it isn’t even supported and will most likely be evolved without much compatibility. The recent release of the WCF version made this clearer than ever. I sort of expected the ASMX->WCF migration to be easily integrated, but no such luck. The WCF Service Factory is clearly separated from the ASMX Service Factory. You decide which one to use and then you’re stuck with it (unless you go through the gruelling 8 step process involving a lot of copy-paste and manual modifications).

Getting to the point I wanted to make. WSSF might make it easier to build the service you’re building today, but I doubt you will use it five years from now. In fact, I’d bet that five years from now someone will look at your service and say “Wow, the data access component in this thing is really difficult to follow. Was there some kind of tool used to generate it?”

Varying Quality Levels

Let’s not kid ourselves here. A bad developer will always create bad code, no matter what tool he/she uses. In fact, if you don’t understand why services built using WSSF are layered like they are or why it is good practice to do Contract First development, then you are bound to make mistakes. So what you’ll end up with is a service that looks like it follows good design practices, but in fact is just as messy as anything else.

Bad Productivity

The biggest problem with the current WSSF offering (in my opinion) is that all recipes are one-time wizards without knowledge of the current code. Whenever you want to make a change to the generated code, you’ll either have to do it manually or you’ll have to run the recipe from scratch again. This may be fine when dealing with the simpler tasks such as adding a new property to a data type. But when you’re dealing with the Data Access classes it quickly gets complicated. I really really hope that the PAG team are working on more Domain Specific Language-like plugins instead. In fact, I think that a good DSL that could help us with mapping data types from the Business Entities to the Service Contract would increase productivity much more than the entire WSSF.

Conclusion.. or something like that..

I strongly believe that in an enterprise that wishes to keep its IT systems reasonably current and its IT department happy, you’ll have to deal with the fact that your code base won’t be a haven of conformity. If you have some junior developers you don’t just hand them a guidance package and say “Follow this and everything will be fine”, you make sure to review their code and you make sure they have a good mentor. If you suffer from bad productivity there are probably many, many things you can do to optimize the way you work (and yes, a tool or two can help – at least to a point). An example of a real productivity booster is another (much more mature) offering from the PAG-team, the Enterprise Library!

When it comes to WSSF I think the PAG team have made a very good effort but I’m sure that they too realize that this technology (Software Factories) is still at a very early stage. It is absolutely a step in the right direction and I’m really looking forward to getting my hands on the next release and the ones after that. Adding some visual DSL tools and getting rid of many of the wizards would make the WSSF extremely interesting.

Please let me know what You think! Have you successfully used the current WSSF and built a better service faster because of it (and will you use it the same way next time)? I’d love to be wrong on this one!

* Straggly Code Base
Is there a better word than Straggly (it’s a direct translation of the Swedish word “Spretig”)? What I mean is when each service is built differently from the last one; maybe it’s layered differently, maybe the naming convention changes or maybe a new Visual Studio extension is used to generate the contract.