PostgreSQL reconsiders its process-based model

Re:PostgreSQL reconsiders its process-based model by hurril on Tuesday June 20, 2023 @03:40AM (#36400854)

The big problem there is that the people you are letting loose on the alternative, are lost from the original, so O loses steam that A gains. You still have to produce bug fixes and features to _both_ O and A to keep them in sync. So you essentially have a doubled required production rate to be delivered using the same staff.

So in order for there to be a net gain, the gang working on the alternative have to be able to find such big wins as to being neigh impossible.

This is a very very hard problem in our domain. 99% of the time, we have to simply resist the urge to _just rewrite the sucker_. No! Don't do it! (And this is incredibly hard because we all want to.)

[ Parent | on HN ]

Re:PostgreSQL reconsiders its process-based model by pphysch on Tuesday June 20, 2023 @01:13PM (#36407221)

Getting some Mythical Man Month vibes here. Productivity isn't a zero-sum game.

[ Parent | on HN ]

Re:PostgreSQL reconsiders its process-based model by hurril on Friday June 23, 2023 @04:54AM (#36444401)

I'm saying that the productivity gain would have to be incredibly large since it has to encompass a doubled output of features and bug fixes for a net zero change.

Say you have product A with features P, Q, R, and S; writing product B has to reproduce P, Q, R, and S, plus X and Y that is currently produced by the A team. On top of that, it has to fix (conceptual) bugs within P, Q, R, and S. All this is to be done by the new, crack, team that aims to make it so that: cost-of-development(B) < cost-of-development(A).

But the point is that the difference in magnitude of cost-of-development(B) and cost-of-development(A) has to be rather large considering the amount of work needed to have a return on that investment at all.

[ Parent | on HN ]