I think PostgreSQL's standards are a bit too high. From my point of 
view, the team as a whole has no desire to build the worlds best open 
source database from the point of view of functionality. They seem more 
interested in the writing the open source database with the world's most 
aesthetically pleasing source code.

Now - in all fairness, I do software architecture for a living, and I 
can't stand hacks. I fight against them *almost* every opportunity that 
I get, because I'm loathe to produce such slop. I know that the more 
slop gets in my code, the harder it is to enhance and maintain, and the 
more likely it is to actually break code & slow down the pace of 
development.

I also must admit that aesthetically pleasing source code almost 
*always* means that the functionality that is there is rock solid. That 
functionality was also 'purchased' at the highest price possible.

But I also know that functionality has value to the customer. Customers 
have very little concern for the aesthetics of proper design and 
implementation. The customer I work with right now has a slogan that I 
think summed it up well for all customers in general: ( I want it all, 
and I want it now ). All the valid technical arguments I have don't mean 
a thing. To the customer, functionality A translates to work savings B. 
The process can be well defined. Implement it. When I tell her that the 
cost of implementation is some high value 'X' ( cost in terms of time 
and/or $$ ), she doesn't say 'I'll wait'. She says. "Hmm... what can I 
get for X/4?" When I tell her, she then says: "Can I get A/4 now, and 
can you give me most of the rest of A in 4 months? That's more important 
to me than functionality Y, and I can do without this bit of spit and 
polish that was part of A."

So I deliver A/4 now, and she uses it now. She receives immediate 
benefit. She uses the product. She's happy. I clean up my hack while I 
deliver the other portion of A that she wanted.

Now I know that business processes are a far cry from database features. 
They are less complex and adding a new feature doesn't always carry the 
potential repercussions that a poorly thought out database feature could 
cause.

Nonetheless, you tell me today that I can shrink indexes with tool X, 
but tool X is a hack and likely to change, and I'll use tool X because 
the value of shrinking outweighs the cost of changing to the 
chrome-plated tool Y when it comes out next year. I may choose not to 
use another tool because it's also a hack and not that important to my 
implementation. My choice. In fact, I've found it less costly to deal 
with vendors cleaning up their hacks( i.e., breaking backwards 
compatibility ) than in trying to implement my own solution for said 
feature and trying to replace it when the database finally implements 
the feature.

I'm not advocating that you put in every hack. There's always a balance 
between judging a whim and a genuine need. A good development effort can 
also tolerate only a limited number of 'unresolved hacks' at a time. 
Fair enough. But an application developer with a need for a database 
feature is going to pick the database solution with that feature set 
implemented *today*. Whether or not it's a hack will not keep them from 
using it. It will keep a seasoned developer from relying *too heavily* 
on it. But there's only so much you can do to protect the users from 
themselves. Warning labels on tools is fair warning.

Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
>> So, when we review patches, we shouldn't be turning up our noses at
>> imperfect solutions if the solution meets needs of our users.
>
> I think our standards have gone up over the years, and properly so.
> The fact that we put in hacks some years ago doesn't mean that we
> still should.
>
> I don't really mind hacks^H^H^Hpartial solutions that are clean subsets
> of the functionality we want to have eventually.  I do object to hacks
> that will create a backwards-compatibility problem when we want to do it
> right.
>
> 			regards, tom lane
Thu, 27 Jun 2002 01:32:53 -0600
Tim Hart <tjhart@mac.com>
Re: Why I like partial solutions