Tuesday, 26 May 2009

It's all in the specifications

Some programmers are happy to dive into the code and get programming straight away. After all, prototypes are useful things, even if they do become production code without much further attention. Are there any risks of this approach, and should developers dive right in?

At the company I work for now, they have developed a fairly complex web application in a short time. I am actually quite impressed with how much has been achieved in about 2 months. I would have estimated it was at least a 4 month development time scale. Has the jump in approach worked in this case?

As a small company, the pressure was to impress the client who set impossible deadlines. The team worked tirelessly and amazingly quickly and produced the application within the deadline and the customer is happy. So this is all good right? Well, let's take a step back and look at what the requirements for this application were.

Right from the outset, the platform that was being developed; to be used by this first client on Oracle. The client uses Oracle, and wants to host the application on Oracle. However, the application is developed using MS SQL Server. Surely, whenever you are starting a new project, you must look at the requirements and develop accordingly. Since this platform is to be reused, clearly, as a company, we want to use MS SQL Server as it is where our strengths lie. So, therefore, the requirement MUST be that the application must be able to communicate with MS SQL and Oracle databases.

Sadly, this basic observation has been missed. Due to the speedy coding of this application, it seems little care was taken in thinking how it was to be installed, on Oracle, at the client's offices. In fact, the technology used was LINQ to SQL. As you may be aware, it is really "LINQ to MS SQL Server and nothing else". So my task for the next 2 weeks is to find a solution to the problem that was known at the outset. We've gone down one path, and now I need to find a solution that will help us use both SQL and Oracle servers.

Options Available:
- NHibernate is an ORM mapper, like LINQ to SQL (but better, richer and DB Server Neutral)
- LINQ to Oracle Component.

NHibernate ORM
This is a powerful option, but the specifications state that they are using Oracle 11g (helpful to read these!) and NHibernate currently seems to have Dialects up to 10g. While it may be possible to work around this (there can't be THAT much difference between the two versions!) we must prove this concept and not just assume it will work. This is an important lesson to learn before picking any technology. It must solve the problem/meet the requirements.

I have created a test application which works with SQL 2005 and now I am having issues connecting to the Oracle. Working out the configuration is the first hurdle, (I think this has been solved, i will post how it all works when complete) now it cannot find the tables. This is probably my lack of Oracle knowledge, than an NHibernate issue.

Should I get this working, it will mean a complete re-write of the data access code. Oh Linq to SQL uses it's own generated classes which I might be able to steal and remap, else it might be worth re-writing. Since each developer has their own dbml in their projects, and code sharing is not a technique they feel is worth doing. I will have to rewrite 4 Data Layers (admittedly it will be with ONE! single shared DAL dll.

LINQ to Oracle
So if NHibernate is so much work, surely this option sounds the best. It might be, and it is an option I will consider carefully. Link to Oracle is a 3d party component which we'd need to buy (circa £1k). We would also need to rework some of the classes / namespaces and would want to create a single Data Layer dll. I will also need to remember the requirement to connect to BOTH SQL Server and Oracle, else we'll be stuck with an application only able to talk to Oracle.

One option could be to abstract the methods to an interface, and have an Oracle implementation and SQL implementation, and load the correct one up depending on a config setting. NHibernate would handle this automatically.

Nothing has actually been concluded yet. Both options involve lots of (avoidable) work and again with time constraints, the most elegant solution might not be the best. This must be complete in two weeks and could have been avoided if the requirements had been thought about.

So I asked the question, whether developers can jump into code. I think the answer is No. There must be some time spent considering what is required. Even if it is a short time, some time is required. This lack of thought/assumptions will result in longer development time and headaches further down the line. Agile development will only work if you keep your eye on where you need to be otherwise, you can be going down the wrong path from the very beginning, with little or no way of getting back on track easily.

There is an old saying:

If you fail to plan, then you plan to fail


  1. One of the best things I ever read - in 'MMM'; namely, "plan to throw one away, you will anyway".

    One of the big[ger] problems here is that unless you're working on a T&M basis, you're on 'fixed' budget, function, and delivery-date - and, in that case, when the deadline approaches, and you're not done, what will suffer? Function *has* to be delivered, and so it has to be quality?

  2. The other option is moving the deadline. While this is not always possible, with an arbitary deadline (as it was in this case) it would be better to up the quality, especially as it is not just for this one customer. The maintenance headache of poor code should be reason enough, but actually producing what is specified (ie Oracle!) is essential.