The Great DB Debate

I am currently working on an application that was very badly coded by another developer. Touching any part of the application is almost certain to embroil me in business rules, SQL statements, xhtml, Javascript, server side code or style sheets. Whatever I do, I almost always have to rely on my knowledge of the database to make a simple change to the application or fix a bug – there is no way around it. The database and the application are tightly coupled, and not even my client thinks of them as two separate entities.

I am inclined to make the decision that the business logic should live in the database, and that the database should be exposed to application developers by means of efficient and correct stored procedures. I am inclined to separate the responsibilities of team members:

• Web designers should build standards compliant web pages.
• Application developers should write server side code to fetch data from the database to be passed to templates that we built by web designers, or they should pass data to the database from the UI, responding to any errors that occur.
• A DBA should be responsible for building a database that performs well, is flexible and adheres to, expresses and applies business rules. And, the DBA should expose procedures that make the data available to developers

As far as I am concerned, the singers should sing and the dancers should dance. Even if I were the sole developer, I would be inclined to build things this way. I want it to be easy for my client to find someone to work on the application. If they want to change the look and feel, the should not have to hire someone who can write or read SQL statements.

I am attracted to ORM tools like Hibernate, or, in my word-a-day Microsoft centric world, NHibernate. I like SQLAlchemy, and SQLObject, and I agree with the goal they try to achieve. Application developers should be spared the pain and inconvenience of dealing directly with the database. Not all developers are able to build a good database, and not all applications should require them to mess with SQL. Fair enough. Ruby on Rails rocks for certain types of applications, and I can see why it is catching on.

However, I CAN build a good database, and I want to. I specialize in applications that contain many rules, and run against databases that may be required to grow and change over the years. Often, my databases have been used by multiple applications, not just one. I need to know that the rules will be applied well no matter what language is used to write the application. I also need to know that the database will perform well, and I do not want to rely on the poorly written queries the developers often write. (It is not their fault, DBAs do not always write good code.)

Since the dot com meltdown, many of my clients have started to look for the one-stop-shop. They would prefer to hire one developer to do all of the work in order to control the project budget. My experience, as a consultant who often gets asked to work on somebody else’s code, is that the one-stop-shop does not work. Often, the result is a bad database sitting under an inflexible web application that is not standards compliant.

Basically, I like stored procedures, and I am suspicious of frameworks and the magic they perform. In my own free time, I can see myself playing with Ruby on Rails, Turbogears, Hibernate, or some other framework. But, I would want the flexibility to use and take advantage of my database skills. Am I being a fuddy-duddy? I like MVC frameworks, but I still want to be use my database skills.

For a discussion of what some of us experience, see this complaint about Ruby on Rails in the enterprise.

I Could Not Care Less What System You Use

This essay by Jeffrey Veen on why content management fails is right on the money. I will not repeat his main points, but I just want to make some quick comments.

I cannot count the number of times that I have engaged in conversations about the merits of various content managements systems. Does it matter? Perhap it matters, but what matters more is to plan how you are going to manage content in the enterprise. Planning includes defining process and workflow, and determining how to staff positions on a content management team. Planning may even invlove defining what you mean by content. For example, there could by FAQs, press releases, internal news, internal blogs, training materials, policies and procedures, staff directories, on-line threaded discussions and so on.

In the begining, it does not matter which system you use. It matters that you can plan the work and establish a budget. Then, choose the system while mapping it to your budget and needs. I have seen many content management projects fail because they were too open-ended, or because they were incorrectly defined. I was once involved in a major initiative by a large fortune 100 company that spent tens of millions of dollars and got nowhere.

Sometimes, I talk to developers who are working on projects that they call ‘implementations’: as in, we are implementing a content management solution using Hummingbird. I will often press these developers to explain the problem they are trying to solve. After all, how can you say that you are implementing a solution if you cannot state the problem? The developers will often say that they need a system that can retrieve both formatted and unformatted content. They will also pepper the discussion with all the right catch phrases and acronyms: XML, faceted metadata, fulltext indexing, and many others.

However, it is obvious to me that the developers are solving their own problems first. It is MY problem as a developer to find a way to search both structured and unstructured content, but users do not care. The user wants to find a press release, a biographical reference or a piece of correspondence. When these gigantic content management projects launch, the users do not like them, or they feel intimidated by them, or they find themselves without the team structures and processes to use the solution. The project fails, and the developers blame the users.

So, ok – I ended up repeating Jeffrey Veen’s main points. I couldn’t help myself.

NOTE: To be fair, there are cases when large organizations, like the Provincial government of Ontario, tries to provide a solution for extremely large groups of users in multiple business units. Sometimes, the idea is: build it and they will come. A lot of good thinking goes into these projects, but I cannot help but thinking that the task is too big. Time will tell. Personally, I do not think one size fits all.

Ask The Dumb Questions

Programmers have a reputation for being smart. I am not sure that is always true, but I do know that that stupid programmers seem to think they are fantastically smart. They love complexity, and tend to look down on anything simple. I tend to like simple things. I won’t say that this means I am smart, but simplicity and elegance often go together. Just because it is easy to understand does not mean it was easy to conceive of.

I ran across the following article entitled “Why Good Programmers are Lazy and Dumb”, and I found it interesting. This entry received several comments. My favorite was: “I r lazy.”

My years of programming have shown me that smart people can become their own enemies. For example, I cannot count the number of times I have assigned work to a programmer only to find him sitting there later in the day trying to fugure out why his code does not work. Long after it is obvious that it is time to come up with an alternative solution, the programmer will try to find out why his solution does not work – after all, it SHOULD work. I have to remind the programmer that his job is to provide a working solution – not to understand why a solution does not work. Smart people can become side tracked by their own curiosity.

We all go through a phase of thinking that we are smart. I can remember spending hours ensuring that my code on a particular project was reusable, only to realize years later that I had never reused it and never would.

It turns out that the real skill is knowing when to make code reusable not knowing how to make it reusable. Many programmers think they are smart when they know how to do something – knowing how is only the beginning. Sometimes it pays to ask the stupid questions:

1. Is this framework really necessary?
2. Will I ever use this code again?
3. Am I working to hard to do something that should really be easy?
4. Does doing things the so-called smart way always have to be so hard?

« Previous Entries Next Entries »