5 ms·

> The highest-order lesson I draw comes from the fact that that Postgres defied Fred Brooks’ “Second System Effect” [Bro75]. Brooks argued that designers often

> The highest-order lesson I draw comes from the fact that that Postgres defied Fred Brooks’ “Second System Effect” [Bro75]. Brooks argued that designers often follow up on a successful first system with a second system that fails due to being overburdened with features and ideas. Postgres was Stonebraker’s second system... I really hope we pull off some of these software adages.

VectorLock 6y ago
>Postgres was Stonebraker’s second system. What was his first system?
- deleted 6y ago
  [deleted]
- fiddlerwoaroof 6y ago
  Ingres. https://en.m.wikipedia.org/wiki/Ingres_(database) https://en.m.wikipedia.org/wiki/Ingres_(database) However, if you look at the projects he’s worked on, he has a track record of writing database engines that end up in delivered database systems.
- jonas21 6y ago
  Ingres. The "post" in Postgres refers to the fact that it was the follow-up to Ingres.
- arminiusreturns 6y ago
  I am really interested in his latest work with SciDB and VoltDB also. Cool stuff to check out if you haven't yet.
mjw1007 6y ago
On the other hand, a lot of what made the original Postgres distinctive has ended up being either removed or considerably downplayed: the "object-relational" features, rules, versioned data, and so on. (I think what the paper refers to as "versioned data" is the "time-travel queries" stuff, not multi-version concurrency control which was added after Stonebraker's time.)
- sbuttgereit 6y ago
  I would agree with you on rules point... at least relatively recently so once instead of triggers for views were on the scene... but I see some fairly robust use of the object-relational features and don't see much downplaying of them. Mind you, that doesn't mean they're necessarily commonplace (or necessarily should be)... My guess is the audience here on HN is less likely to run into these features in their day-to-day lives. By my observations, the HN audience tends to be generalist developer types that will readily just hand off database specialization to the most popular ORM layer for their first class development environment. And I would agree they'll not encounter these things... and if they do, they'll largely be annoyances. I work in "enterprise" type software and I see and do a lot of specifically database development (for PostgreSQL usually these days). If we consider PostgreSQL's type system as part of the object-relational feature set, I find I make use of that fairly frequently, for example compound types... also understanding that object-relational shouldn't be confused with "object-oriented". In my own work it's primarily the more advanced typing that shows up in both procedural code I write as well as queries in certain cases. Less so, though not completely absent is the inheritance feature; there are uses for it for sure, but a rather narrow set of cases (I mean outside of partitioning, which is the most common use case). Anyway... I'm not so sure it's really a matter of downplayed as much as it is less generally understood as PostgreSQL has become more popular.
debaserab2 6y ago
I don't think the fact that someone made a second version without succumbing to second system effect disproves the adage outright; for the vast majority of new programmers it's still worthwhile advice to adhere to. Like any principle or adage, if you are experienced enough to deeply understand the reason for it, you will know when it does or does not apply.
- redler 6y ago
  Postgres is truly an exception that proves the rule. "Sure, not every second system falls prey to this phenomenon, but you practically have to be Postgres to avoid it."
  - fnord123 6y ago
    >Postgres is truly an exception that proves the rule. That's not what "an exception that proves the rule" means. It means "you may walk here" implies (proves the rule) there is a rule that you can't walk elsewhere. In any event, plenty of second systems are fine. It's ridiculously outdated advice. Any time someone replaces their Flask web app with a go or rust version, qed.
    - redler 6y ago
      An "exception proving the rule" is a colloquial phrase that can be interpreted in several ways. Yours is one of them. I'm using it here as a fun way to underscore the decades of consistent greatness of Postgres[QL], and the folly of using one of the most successful open source projects in history as a counterexample to Brooks's "second system".
      - deleted 6y ago
        [deleted]
    - jlokier 6y ago
      Your meaning is not what "the exception that proves the rule" means in my experience from ~30 years ago. In my experience, it means: "This thing stands out to us as exceptional because it is exceptional; there is a rule which normally applies, but we tend not to notice the rule until an exception to the rule reminds us of the rule by contrast".
touisteur 6y ago
Sadly, I've seen this happen still too many times (Second System Syndrome, where all scope of the original 'tech refresh' is lost) and there's often not much (powerful enough) to oppose to people that fear being the hated authors of the new system ; they hated the author of the old system... The righteous "this time we'll do it right" is a powerful drug, and fear of missing something can drive even the most experimented people to stupidity...

VectorLock 6y ago

>Postgres was Stonebraker’s second system. What was his first system?

deleted 6y ago
[deleted]
fiddlerwoaroof 6y ago
Ingres. https://en.m.wikipedia.org/wiki/Ingres_(database) https://en.m.wikipedia.org/wiki/Ingres_(database) However, if you look at the projects he’s worked on, he has a track record of writing database engines that end up in delivered database systems.
jonas21 6y ago
Ingres. The "post" in Postgres refers to the fact that it was the follow-up to Ingres.
arminiusreturns 6y ago
I am really interested in his latest work with SciDB and VoltDB also. Cool stuff to check out if you haven't yet.

mjw1007 6y ago

On the other hand, a lot of what made the original Postgres distinctive has ended up being either removed or considerably downplayed: the "object-relational" features, rules, versioned data, and so on. (I think what the paper refers to as "versioned data" is the "time-travel queries" stuff, not multi-version concurrency control which was added after Stonebraker's time.)

sbuttgereit 6y ago
I would agree with you on rules point... at least relatively recently so once instead of triggers for views were on the scene... but I see some fairly robust use of the object-relational features and don't see much downplaying of them. Mind you, that doesn't mean they're necessarily commonplace (or necessarily should be)... My guess is the audience here on HN is less likely to run into these features in their day-to-day lives. By my observations, the HN audience tends to be generalist developer types that will readily just hand off database specialization to the most popular ORM layer for their first class development environment. And I would agree they'll not encounter these things... and if they do, they'll largely be annoyances. I work in "enterprise" type software and I see and do a lot of specifically database development (for PostgreSQL usually these days). If we consider PostgreSQL's type system as part of the object-relational feature set, I find I make use of that fairly frequently, for example compound types... also understanding that object-relational shouldn't be confused with "object-oriented". In my own work it's primarily the more advanced typing that shows up in both procedural code I write as well as queries in certain cases. Less so, though not completely absent is the inheritance feature; there are uses for it for sure, but a rather narrow set of cases (I mean outside of partitioning, which is the most common use case). Anyway... I'm not so sure it's really a matter of downplayed as much as it is less generally understood as PostgreSQL has become more popular.

debaserab2 6y ago

I don't think the fact that someone made a second version without succumbing to second system effect disproves the adage outright; for the vast majority of new programmers it's still worthwhile advice to adhere to. Like any principle or adage, if you are experienced enough to deeply understand the reason for it, you will know when it does or does not apply.

redler 6y ago
Postgres is truly an exception that proves the rule. "Sure, not every second system falls prey to this phenomenon, but you practically have to be Postgres to avoid it."
- fnord123 6y ago
  >Postgres is truly an exception that proves the rule. That's not what "an exception that proves the rule" means. It means "you may walk here" implies (proves the rule) there is a rule that you can't walk elsewhere. In any event, plenty of second systems are fine. It's ridiculously outdated advice. Any time someone replaces their Flask web app with a go or rust version, qed.
  - redler 6y ago
    An "exception proving the rule" is a colloquial phrase that can be interpreted in several ways. Yours is one of them. I'm using it here as a fun way to underscore the decades of consistent greatness of Postgres[QL], and the folly of using one of the most successful open source projects in history as a counterexample to Brooks's "second system".
    - deleted 6y ago
      [deleted]
  - jlokier 6y ago
    Your meaning is not what "the exception that proves the rule" means in my experience from ~30 years ago. In my experience, it means: "This thing stands out to us as exceptional because it is exceptional; there is a rule which normally applies, but we tend not to notice the rule until an exception to the rule reminds us of the rule by contrast".

touisteur 6y ago

Sadly, I've seen this happen still too many times (Second System Syndrome, where all scope of the original 'tech refresh' is lost) and there's often not much (powerful enough) to oppose to people that fear being the hated authors of the new system ; they hated the author of the old system... The righteous "this time we'll do it right" is a powerful drug, and fear of missing something can drive even the most experimented people to stupidity...