Re: The crime under reusability

[tilly]

I'm going to go out on a limb and ask if the lack of joins is really the reason for the performance problems.

No, I am not saying that I think that they made a good design decision. Rather, I am saying that I can think of many additional further mistakes which they could make which could result in the same symptoms, but without which their performance might have been still OK. Here is a sample:

• Is there a good one-to-one mapping between database-backed objects and application level screens? If there is then you have surprisingly little need for joins. You can't always aim for this, of course. But when you get it in a web-based environment, you literally can't make much use of joins.
• Did they have appropriate indexes? Indexes aren't only used for joins. If you ask for all accounts that are represented by representative X, having an index on account_rep_id will be useful whether or not you are joining.
• Did they use placeholders or an equivalent? From your description we can answer that in the negative since the WHERE clause was passed in as a string. I believe this to be a worse decision than the lack of joins. First there are the security reasons stated in Use placeholders. For SECURITY!. But secondly some databases (Oracle would be a good example) go out of their way to try to cache used queries, and contention for that cache will make them fall over fast if you force them to parse everything. (Oracle specifically has a setting that makes it rewrite everything with placeholders. This doesn't solve the security issue, but might help their performance issues.)
• Were they using Enterprise Java beans? Multiple Java experts of my aquaintance have told me that performance with beans ranges from bad to worse. I have heard of plenty of projects with good performance using direct DAO. I've heard of none with beans.

And my point is that just because you know that they did one thing wrong, and had predictable problems, doesn't actually prove that the mistake you see is what actually went wrong.

UPDATE:

lachoy is exactly right. Updated.

[hardburn]

The points you make might show that the performance isn't due to this design decision, but I don't think it solves the points about maintainability. In particular, the OP noted that the programmers didn't have an understanding of the user requirements. No ammount of good design will save you if you don't really understand the problem.

[tilly]

I wasn't saying that this design decision didn't cause the performance problem. I was instead saying that without a detailed post-mortem, you shouldn't conclude that it was that. Personally I'm never comfortable with conclusions unless I have been balancing at least three theories. One theory is usually prejudice. 2 gets me into binary thinking where I have a hard time really thinking through the merits of either. 3 seems to be my threshold to really start breaking things down and identifying what is going on.

Also when a project goes wrong, it usually goes way wrong. My suspicion is that the database decision is more of a symptom than a cause. The poor understanding of user requirements is another symptom. Firing the project manager is suspicious. I'm sure that if I knew more about the project failure, I would come up with lots more symptoms.

Symptoms of what, though, is a different story. Were key people not properly prepared for their roles? Does the company have a command and control philosophy which results in more CYA than useful early feedback about potential problems? Was the wrong kind of project structure for the problem in use? Did you have a deathmarch? (These are not mutually exclusive possibilities...)

There are plenty of classic books from Peopleware which have lots of useful stuff to say on why projects fail and what you can do about it. But without knowing some details, there isn't much that you can concretely say about what should have been done better on any given project.

Which is why I limited myself to pointing out other possible technical performance problems other than the obvious which plausibly played a role.

[bart]

What's a deathmarch? Somehow the (cliché) image of lemmings storming towards the cliff's edge, comes into my mind's eye.

[lachoy]

Just a nitpick - you probably mean Enterprise Java Beans instead of Java Beans. The former are the Java-blessed way of creating distributable components, the latter a fairly simple specification for exposing properties of an object. It's unfortunate they're so similarly named.