Re: [HACKERS] Why I like partial solutions
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 [EMAIL PROTECTED]> 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
Re: [HACKERS] Why I like partial solutions
On Wed, 26 Jun 2002, Tom Lane wrote: 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. If the backwards compatability problem is just related to stuff from the users (i.e., this keyword works in this release, but will not work in future releases), I don't see the problem. Just document it and move on. The user can either use it and deal with the compatbility pain later, or not use it and be just where he would be if the hack were never implmemented in the first place. Otherwise you only have to leave the feature in until the next major release, anyway, right? Because for major releases it's expected that you will have to dump and restore you database anyway, hmm? cjs -- Curt Sampson [EMAIL PROTECTED] +81 90 7737 2974 http://www.netbsd.org Don't you know, in this new Dark Age, we're all light. --XTC ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Why I like partial solutions
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] 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. I absolutely agree on that. If we at some point want to have a given feature, we need to avoid backward compatibility problems. As for features that are independent, don't break anything, just add-on's that can happily swim around in contrib (but stay out of the deep water), we might want to become a bit more relaxed again. Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Why I like partial solutions
I find myself repeatedly arguing for partial solutions, and having to struggle with other developers who feel these solutions are hacks. Let me explain why I like these hacks. When we have a feature that users want, often we can't get it implemented promptly in a clean way. It can take several releases for someone to focus on the problem, re-factor the code, and get the feature in there properly. While we are waiting months, often years, for a features to be properly implemented, our users have no solution except to wait for us to implement it. At the same time, there often is a way to implement the feature partially, often unattractively, so that users can use the feature until we get around to implementing it properly. When I think back on many of my code contributions, a lot of them were such hacks: temp tables, optimizer statistics, indexed LIKE in gram.y. Many people hated that last one, and I got all sorts of grief because it was done in such an ugly way, but it was used for years until the feature was properly implemented in the optimizer. Same for temp tables and optimizer statistics. That code is gone now, and that is fine. It was easy to rip out once a proper solution was made, but it served its purpose. So, when we review patches, we shouldn't be turning up our noses at imperfect solutions if the solution meets needs of our users. We had DROP COLUMN and NO CREATE TABLE solutions suggested many years ago, and because the solutions weren't perfect, we don't have those features, and users who needed those features have had to move to other databases. How many users have we lose just on those two features? Sure, now we will have schemas in 7.3, but we could have given users _a_ solution years ago; not a prefect solution, but enough of a solution to keep them using PostgreSQL until we implemented it properly. Maybe this is marketing, but when people repeatedly ask for a feature, and we can implement it with a partial solution now, I think we should do it, rather than saying Oh, we can't do that properly so we will just do nothing. If we want to grow PostgreSQL, we need to meet users needs, even if that requires stomaching some hack solutions from time to time. That's why I like partial solutions. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup.| Drexel Hill, Pennsylvania 19026 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Why I like partial solutions
-Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] Sent: 26 June 2002 19:21 To: PostgreSQL-development Subject: [HACKERS] Why I like partial solutions If we want to grow PostgreSQL, we need to meet users needs, even if that requires stomaching some hack solutions from time to time. That's why I like partial solutions. Apologies for the breach of netiquette: I agree. Regards, Dave. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Why I like partial solutions
Bruce Momjian [EMAIL PROTECTED] 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 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
