I want no monuments

It was since the beginning of my career as a software developer that I’ve seen too many devs building their so called OO apps on top of some database.

I mean those apps were nothing without a DB and things like event notifications were done (”are” done, actually) through the db: some polling task looking at a table for new things to do.

Every of these projects has a common pattern:

1. they are started thinking at the database, and the objects structure and hierarchy is a consequence of the relational structure of the tables
2. db fans have built a perfectly normalized db, but it is slow: too many “joins”, indexes that cannot be created because the DBAs fear the loss of speed (remember: fear is a consequence of ignorance. If you fear something, you don’t know something). DBAs de-normalize the db, keeping it in sync through stored procedures and triggers.
3. the customer asks for some new feature that would have been just as simple as a decorator, BUT since your object hierarchy is still reflecting the DB structure, you realize very soon that you would need to modify a couple of different classes instead than adding one. And because you fear (fear! again) to modify your code, you ask the DBA to adapt the DB structure to your needs: and so views, stored procedures and functions start to pop up like pustules.
4. step 3 is repeated ad nauseam for a whole year or so. The team is exhausted by the continous effort put on maintaining the app (that’s what I call “kick programming”, that’s stacking quick, dirty and violent solutions to small problems). Some of the older team members leave as they like to be programmers, not maintainers. Junior developers replace them, and things go worse, as a junior may not have enough experience and being new to the team means he/she doesn’t know the app well enough to keep on maintaining it even at the low quality level of the old programmers.
5. I still don’t know, I’ve never seen that, but I know there is still some fifth point. Maybe the project is kept on by people who “just code”, continously patching the whole thing. Maybe the project dies. Maybe something else…

All this mess JUST because someone has given the DB more importance than it deserves.

Remember: a database is a place where you put things when you leave the office, because you’ll need them the day after. Period.

It’s a base to put data on: no logic, no influence on the project.

Have you ever thought at your desk drawer as a player in your project management or design process? I don’t think so.

This entry was posted on Saturday, September 29th, 2007 at 10:47 am and is filed under Business, Software Development, Knowledge. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.