This is a real life story, and it actually got my immediate manager fired (of course this is only part of the reason why she got fired.)

We had a project to replace our entire merchandising system, which is currently running on IBM mainframe. According to the original project plan, it is supposed to be in production already, but it is not, and will not until next Sep. Luckily I was not part of the team. The project is not in Perl, so this is OT. But the lesson it taught is across languages, so I think just share.

Although the system will only be used by internal users, the team decided to make it a web application. That's cool, and I guess that's one of trend going on today.

The code is OO, and as a general principle, the team decided that all the database queries should be wrapped in DAO's (Data Access Object). So to the rest of the system, no code accesses database directly, instead, only accesses database through DAO's. This is still cool, and is still on the right track.

Then the next idea brought the whole design to a level of insanity I had never heard of before, actually even never ever had the slightest thought of. Unfortunately because it was proposed by a senior designer, and backed up by the manager, it got passed the design review, and even had everything implemented. The reusability of those DAO classes seemed to be so important to that designer, and through his past experience, he realized that all the SQL queries were different, thus the DAO's used to wrap them were not reusable. In order to have a quantum leap of reusability, he made a design rule to his team: there shall be no joins in SQL queries, and the join shall be handled in (programmer's own) code. Now instead of having a big number of DAO's for all SQL queries, they only needed to create one DAO for each table to wrap a single dynamic query. The query accepts a string parameter that will be used as where clause, and returns a result set that holds all columns of the table. Now the reusability is largely increased, as there would be only one DAO for each table, and it is reused whenever you need data from that table.

What a brilliant idea! What a stupid crime committed under the beautiful cover of reusability.

It was until the point they started to system test what they created, the team suddenly discovered a nightmare that could never be waken up:

• Their system had a terrible database access performance, without table joins. Till today I still don't understand why the guy didn't realize that, reusability not only means to reuse the company's own code, but also means to reuse the join functionality provided by the database. I think I will never understand.
• Their system is not debugable and not fixable. They never actually got rid of the join, the truth is that, instead of using the join provided by database for free, they did their own join, and the join logic was spreaded all over the system, to debug and fix it was simply not humanly possible, within the time frame of the project.
• There were other problems in that project, such as they never clearly understood the user requirements. I am thinking, had they not wasted all the time they spent on those meaningless things, they could saved it and spent to understand user requirements.

Everyone likes reusability, and it is right and beautiful, but just like any other wonderful things, if you over do it, you kill all of its good purposes, and create evil.

You don't believe this story? me either, it just sounds so unreal, and I really wish it had never happened.