3 ms·
There's something wackadoo going on in software where in one environment it'll take 200 workers six years to have something that's still not good, and in anothe
by wharvle 3y ago
There's something wackadoo going on in software where in one environment it'll take 200 workers six years to have something that's still not good, and in another it'll take 1-5 workers a couple years to do at least as well.
It's not even a corporate vs. small shop thing. Look at the team sizes on "giant" programs from big companies in the 90s and consider how enormous an undertaking they'd be considered by most software orgs today.
Like, I get all the Mythical Man-Month, Brooks' Law stuff and that that observation predates the period I'm talking about, but there's definitely been some kind of shift that has other factors causing this (with Brooks' Law compounding the problem). Not sure what it is, I just know that it sure looks like we're far less efficient at building software than we used to be (where "we" is the industry overall). It's like every single organization larger than a dozen people got way worse at building software, pretty suddenly, some time between about 2005 and 2010.
- webmaven 3y agoI think you're missing the factor that expanding the API surface area, however attractive/productive/cool each individual expansion/feature might be, in aggregate becomes a moat maintaining the incumbent's dominant position. So as far as Google is concerned, the implied manpower requirements are a feature, not a bug. Chrome's surface area is now huge (and still expanding at a fair clip), but matching Chrome's featureset has become table-stakes for being considered a viable desktop browser, and independently implementing (and maintaining) that entire set of features requires a correspondingly large developer team, even if you were somehow more labor-efficient.