Earlier quoted context omitted.
A few hastily considered thoughts in response: I really don't understand why you think "convexity" is a new concept. Isn't this the way most if not all artisan crafts have worked since antiquity? Master-apprentice and guilds. Either software creation is an engineering discipline or it is a craft. You seem to be cherry-picking. Also I believe that while your characterization of open-source projects as essentially ego…
I really don't understand why you think "convexity" is a new concept. Convexity's not new. What is new is the inability for humans to compete with machines on concave labor. Convexity and concavity come (in theory, anyway) from the logistic form: L(x; ...) = V + A/(1+exp(-S(x-D))) It grows exponentially (convex) over x > D, leveling off to meet a horizontal asymptote at x = V + A. V is a vertical offset, A is maximum…
>>> Also I believe that while your characterization of open-source projects as essentially ego trips may be accurate of some
Oh no, that's is not what I am saying at all. >>>
I apologize if I have misunderstood, but you argued above that one of the reasons for the explosive growth of OSS projects ("cool stuff for free") is because it is primarily a means to gain recognition to "shortcut" the monotony of apprenticeship. That seems to me not entirely but mostly an egotistic motivation ("Look at me, I'm good!").
>>> We're just going to disagree on this one [about whether the merits of the work of engineers can only be judged by superior engineers] >>>
And so you think that software which at its most fundamental level is a literary endeavor is immune from critique? That borders on the inane and almost requires a leap of faith. Nearly the same argument is made that the Bible is truth and not subject to any criteria except by those of its authors to be accepted by its reader and interpreted only by a sanctified priesthood. Do you also believe art, film, literary, etc criticism is devoid of value and entirely subjective?
Your example is also ridiculous. As if the management of any successful or functional technology company has as much relation to its product as that of a stupefied onlooker to a magic show. Most if not all managers of technical projects are previous engineers. That is one of the major criticisms of the profession by engineers. You reach a stage of ageism where career growth mandates the switch to management. Your analogy of you marching into a EE shop is I assume mirrored by a Dilbert-esque characterization of a pointy-haired boss marching into a technical meeting and arbitrarily dictating software decisions based on whether he likes the name ("Sharding sounds cool")? This may match your own experience but certainly doesn't match mine. What usually happens is after a failure is a conversation like...
Manager: You said sharding would solve our business problem.
Engineer: Yes but you didn't tell me about this feature which entails .
Even chefs and cooks are judged based on the success of the output of their secret recipes; that it meets the requirements of the restaurant and it suits the taste level of its customers. Why is software intrinsically different? You haven't convinced me so far.
>>>> Sorry, but that's nonsense. If anything, we lack bargaining power over management, >>>>
And here I can not follow as you go off the rails. You just argued that technology managers have a complete inability to complete the work by any other means than using specific skilled labor they cannot understand. This is the very definition of bargaining leverage.
Moreover, you have spilled much ink arguing that the only reason to value skilled technology workers of high multipliers is that they are hard to replace (they have an innate value). That means second-tier and lower tech workers ability to remain relevant and increase their prospects is to emulate by whatever means their higher-value peers since they cannot hope to attain such a valuation on their innate skill. That is why average engineers seemingly go to great lengths to obscure results/defects and provide no objective means to judge the output of their software teams. It does not follow that such macroscopic categories by which to judge software quality do not exist.
Also as an off-topic aside in my humble opinion this is why we have seen such a dramatic rise of "agile", chaotic processes over more established, disciplined methods to manage software production. It is not that disciplined and established production techniques fail to predict accurately the outcome of software projects; it is that they do too good a job at illustrating how immature software engineering/craftsmanship actually is. To be fair, software manufacturing has had a relatively short go at it ;-)