I am surprised by the use of PHP as an exmaple here. I thought PHP was notorious for it’s early inconsistencies because it was basically one person’s personal project.
I think that actually shows that the real issue is cohesive vision. This can be achieved by individuals or groups. Of course it gets harder as the group becomes.larger, but it isn’t free or automatic with individuals either.
All I will say is that most of the example given for a “dictator model” are actually not a dictator model.
There are other models than the two offered there. Rust is a good example. Teams are committees, mostly of whoever work on this part of the system. And the IC can decide things by themselves. There is also a RFC process. It does not need full consensus.
I understand the drive to impose a simple and easy to describe structure to complec projects but in general, complex projects do not work this way. We are just not as used to it.
I’m aware of the saying. It’s an ignorant, flippant one.
Try moving goods across the Sahara on horses, see how far you get.
Camels have an ecological/economic niche, just like programming languages. PHP’s success, and its defects, are only partially attributable to the governance of the project. In fact, a ton of PHP’s issues can be traced to its creator, Rasmus Lerdorf. Maybe if he’d sought the advice of others, it wouldn’t be a byword for bad design.
On a subjective note, I also found the second camel picture (described as “the finishing touches” being “far from ideal”) to be actually kinda cute. Maybe I’m just hallucinating but looking at this camel’s eyes and the way the photo was taken it looks like a curious creature that would like to be your friend.
I do actually think that, as some other comments sorta suggest, this isn’t actually about individuals vs. groups. like I have been in technical committees which were amazing and made excellent engineering decisions.
that’s partly about the experience of the people involved, and in particular about whether they’ve learned the hard way to take the small stuff seriously… but I would argue it’s mostly about the human parts of the process, the stuff few people in technical fields are willing to even put a name to.
the engineering mindset requires us to find names for things and reason about them explicitly. when there are important constraints that we refuse to let ourselves talk about, for example because of a misguided belief that feelings are icky, of COURSE we find ourselves unable to reproduce the solutions we come up with and grasping for straws to figure out what’s different about the ones that work.
Interestingly, Facebook maintains a PHP variant called Hack (or Hacklang) which followed the design path the author is suggesting.
But after early success (e.g. Wikipedia was an adopter) it didn’t find much traction outside of Facebook. Largely because PHP incorporated many of the improvements and features from Hacklang into subsequent major versions - removing the incentive for existing codebases to migrate languages rather than just moving to the latest version of PHP.
I am surprised by the use of PHP as an exmaple here. I thought PHP was notorious for it’s early inconsistencies because it was basically one person’s personal project.
I think that actually shows that the real issue is cohesive vision. This can be achieved by individuals or groups. Of course it gets harder as the group becomes.larger, but it isn’t free or automatic with individuals either.
All I will say is that most of the example given for a “dictator model” are actually not a dictator model.
There are other models than the two offered there. Rust is a good example. Teams are committees, mostly of whoever work on this part of the system. And the IC can decide things by themselves. There is also a RFC process. It does not need full consensus.
I understand the drive to impose a simple and easy to describe structure to complec projects but in general, complex projects do not work this way. We are just not as used to it.
This piece is unfair to camels.
It’s a preexisting saying: “A camel is a horse designed by committee.”
I’m aware of the saying. It’s an ignorant, flippant one.
Try moving goods across the Sahara on horses, see how far you get.
Camels have an ecological/economic niche, just like programming languages. PHP’s success, and its defects, are only partially attributable to the governance of the project. In fact, a ton of PHP’s issues can be traced to its creator, Rasmus Lerdorf. Maybe if he’d sought the advice of others, it wouldn’t be a byword for bad design.
On a subjective note, I also found the second camel picture (described as “the finishing touches” being “far from ideal”) to be actually kinda cute. Maybe I’m just hallucinating but looking at this camel’s eyes and the way the photo was taken it looks like a curious creature that would like to be your friend.
I do actually think that, as some other comments sorta suggest, this isn’t actually about individuals vs. groups. like I have been in technical committees which were amazing and made excellent engineering decisions.
that’s partly about the experience of the people involved, and in particular about whether they’ve learned the hard way to take the small stuff seriously… but I would argue it’s mostly about the human parts of the process, the stuff few people in technical fields are willing to even put a name to.
the engineering mindset requires us to find names for things and reason about them explicitly. when there are important constraints that we refuse to let ourselves talk about, for example because of a misguided belief that feelings are icky, of COURSE we find ourselves unable to reproduce the solutions we come up with and grasping for straws to figure out what’s different about the ones that work.
Interestingly, Facebook maintains a PHP variant called Hack (or Hacklang) which followed the design path the author is suggesting.
But after early success (e.g. Wikipedia was an adopter) it didn’t find much traction outside of Facebook. Largely because PHP incorporated many of the improvements and features from Hacklang into subsequent major versions - removing the incentive for existing codebases to migrate languages rather than just moving to the latest version of PHP.