I haven’t yet posted much on AI as Software. But now I’ll say more, as I want to ask a question. Someday ems may replace humans in most jobs, and my first book talks about how that might change many things. But whether or not ems are the first kind of software to replace humans wholesale in jobs, eventually non-em software may plausibly do this. Such software would replace ems if ems came first, but if not then such software would directly replace humans.
Attributing a percentage might be difficult, as developer productivity in general is not a well defined not does it have a commonly agreed on definition.
Developer productivity to should be mostly concerned with the outputs – which at the end of the day is still code – the quality of such outputs and the cost of those outputs.
For the last 7 years I been working for the same company which grew from the original 5 people team to a 100 team; and boy I can tell you that at least as far as I'm concerned we got a lot slower.
Put as a percentage I would say some tasks are now taking 200% more time to complete, and while is true that now we see larger projects and we have the ability to tackle much more complex tasks; is the simple ones, the trivial ones that I'm still shocked to see are taking too long to complete.
A larger organization faces a considerable amount of challenges to make sure knowledge transfer, communication and repeatable details are still achieved; a smaller team has the advantage of just turning left/right and asking for help or more information.
I've at times generated more output at small companies than large ones. Hard to say exactly by how much but maybe 200 to 300% more productive at a small firm. Mostly a matter of motivation: in big firms I am not much needed to be more productive and additional productivity has little marginal impact on the business so there's little reason to work harder than necessary. At a small firm my work is often necessary for the firm's continued existence, and the more the firm's existences hinges on my work the more productive I am. But then at small firms I've been no more or less productive than at big firms when my work didn't matter much. But to be fair this is all perceived productivity; I have no outside way to measure well how much work I did other than how much work it felt like I did.
I concur. I am a software developer at Google and when I write a highly-available and global service for millions of users I think I am thousands of percent more productive since many of the tricky problems (security, database, redundancy, backup) are already solved and one can focus on the business logic. I couldn’t do all that from scratch.
Just trying out something small could be delayed a bit by bureaucracy.
But today there are intense competition in the cloud space so key Google technologies like Spanner are available to anyone to rent. So perhaps this was more true 10 years ago.
A well known general rule for software development is that as you add programmers to a software development task, the marginal contribution of each programmer decreases, in large part due to communications and coordination overhead.
As a general case, programmers at small firms are currently able to use essentially the same tools as programmers at a large firm, so there is no inherent scalability advantage there.
In a small company, someone may not be able to specialize to the extent they could in a large company (separate QA groups, configuration management, production support, etc...), but that is only an advantage up to about 20-30 people, after that the benefits stop increasing.
"In the wild", I don't know of any software development teams which scale very far while working together. Looking at publicly available records, the Linux kernel is primarily the work of about 20 developers. There are lots more (10K?) with little tiny contributions, but they contribute way less each than what the top 20 do. For Windows 7, Microsoft purportedly had 23 feature development groups of about 40 people each, for less than a 1000 total, but I think you'd really count "40" as the number working on the "same" software.
So you can make more different products by adding development groups, but you rapidly reach the point of diminishing returns when trying to add developers to the same product. This would seem to imply that a small company of 40 developers would compete just fine with just about any scale of larger company, because they'd end up with a group of about 40 also working on the same problem.
You can consider "complex" software problems, but my experience is that complex software is typically a collection of simpler software which are then packaged together as an overall solution. Maybe someone out there makes a massive monolithic piece of software, but I don't know who would want to. There are advantages to buying a collection from one company to ensure interoperability, support and compatible upgrade cycles, but typically that still leaves room to compete for replacing components if the replacement is good enough and doesn't really speak to the question of developer productivity, just sales ability.
So in short, I'd agree with the others above and say based on experience, "Developers are likely 60% _less_ productive on average working at a big software firm", but that certain sales and packaging advantages keep them there for some software markets.
In games, there are some market-failing exceptions with large teams, but flagship (at the time) products like Sega's Sonic Adventure had a complete team of 30 people. Sonic Heros had a team of 19 people. There are lots of examples. Valve makes a major game engine (Source), lots of games, Steam, etc... with about 100 employees total.
I would argue that a very large source (the main source?) of the marginal productivity gain of working at big firms is the simple fact that big firms have access to a large base of people who are already willing to consume their outputs and do not need additional marketing.
Work at one of AppGooAmaFaceSoft. Probably around 50% - in smaller companies, depending on the company a good 50% of my time would go to (deployment, release, testing, security) and that burden is gone due to tooling that automates a lot of the manual work. There is also a gain that is harder to quantify that comes from having consistently more competent peers to review and assist with catching code problems.
Addendum - I'm not including the cost of understanding the large system i work on, which is of course much higher than at smaller companies. Given that i know the system im working on well, i get more time to focus on direct coding rather than on (deployment, release, testing, security). Also, to address comments others have made that they felt they were more productive at smaller firms. I would agree that I could 'code faster' at a smaller firm, when I was able to focus on coding, but that I got less time to do so because of the abovementioned busywork.
If you follow the money, Google is an advertising company. Techies are more attuned to its shiny technical products, but I suspect the shiny things have a lot to do with Larry & Sergey maintaining majority stake and rather than retiring when they hit it big, preferring to have armies of top-notch engineers to help them make fun shiny things.
But take away the advertising revenue and all that goes away. So perhaps your "magnet for good programmers" theory is correct, but less to do with prestige and more to do with companies that hit the jackpot with ads or taxis or whatever, and then use high salaries to attract a critical mass of sharp programmers to diversify.
(continuing). But perhaps what you mainly care about are big hypothetical futuristic firms that would compete against ems?
Perhaps the firms you're imagining would have limited AIs that do complicated tasks more efficiently than a human. So perhaps a firm solves the self-driving car problem. Or the babysitting problem (keep Junior or great-Grandpa from hurting themselves and provide basic needs). Or writing legal briefs or doing radiology.
In such cases, one key question is whether they can run on the customer's hardware. If a service today needs to query a petabyte datastore, it's going to run in the cloud and be owned by a big company.
Another barrier is IP. Perhaps that petabyte datastore requires sending cars out to map all the streets in the world, or an army of engineers to regularly tweak the neural net.
I'm less concerned about the IP in the core algorithm: usually the techniques end up in academic journals and patent applications. Openstreetmap.org works fine, and its rough edges improve over time, but it's hard to compete with google's map database.
So if we project today's supply market onto the future problem space, my prediction would be lots of open source stuff that lets anybody do some subset of tasks like language translation or image understanding. It took mankind decades to solve the problem, but the solution runs from a tidy library on your phone.
The messier problems like, say, maintaining a database of all the roads and places in the world, or the computationally expensive problems that have to run in a datacenter, would be the domain of the big firms.
One answer is that search and amazon and facebook have to be big complicated systems in the cloud. Amazon needs a big warehouse. Google's web index doesn't fit on your phone. Facebook puts all your friends in one place. So those are necessarily big firms.
But more lucrative and less savory are the walled gardens. Windows and Intel x86 dominated for decades because everybody's apps ran on it. Their biggest strength was also their biggest curse: backwards compatibility kept the customers captive but made it increasingly hard to change anything.
Apple's the biggest company in the world because it figured out how to vertically integrate the hardware supply chain, and produce a single model of phone that works well with the software.
Qualcomm is worth studying: they're cleaning up in the Android market because phones have a huge mess of radio stacks, each with tons of regulatory and IP constraints, and they've been consolidating the ability to put that in a single SoC.
So I guess my intuition is that a lot of the market for big software companies has to do with friction from IP, regulators, standards bodies, and hardware integration. When that friction can be overcome, some hacker in a basement takes care of it for everyone, and creates a public good that nobody pays attention to because it no longer appears on anybody's balance sheet.
> what fraction of software development is general as opposed to industry-specific, and how concentrated is this general software industry.
This is a hard question. Sounds like you already know enough about software to understand the significance of zero marginal cost. If I get everyone to standardize on metric hex cap screws, I can start a big firm producing them by the millions, and small firms can't touch my economy of scale. But software is weird: Dan Bernstein can singlehandedly write all the crypto for the entire world: http://www.metzdowd.com/pip...
Cloud software is a weird move toward *higher* marginal costs for the producer. It's easier for the producer to maintain and support, and opens the door to lucrative tracking and advertising. But it's much harder than just putting a tarball up on github.
A lot of the comments in this thread reflect that zeitgeist: scaling to a billion users means running complex cloud services, and here big companies have an advantage.
So that makes it easy to overlook the commoditized software infrastructure underpinning everything from big cloud services to your mobile phone.
Linux is a big project now with lots of contributors, but it's not owned by a big firm. Lots of the absolutely essential drivers and libraries -- the metric hex cap screws -- are maintained by single individuals in their free time.
So yes, there's a huge long tail of niche software easy for small firms to serve. But unlike mechanical industries, we shouldn't expect the commodity building blocks with huge volume to come from a big firm.
What if different size firms have access to different inputs? More specifically I'm wondering: might the prominence of some large software firms like Google or Facebook be partly due to their prestige, which enables them to attract the best programmers by bestowing onto them status that smaller firms just can't offer?
Right, in my last paragraph, my first proposition is that small systems have an advantage in cycle time.
The second proposition is perhaps harder to see: big companies have infrastructure optimized for big systems, and this makes it harder to build small systems.
The build, monitoring and deployment systems may each be a marvel of big system engineering, more complicated than a small company's entire operation. Small companies can't touch it, but nor are they forced to put up with their inertia and long-tail latency that make those systems painful for use in small projects.
I run a large tech organization, so I think about this problem a lot.
"Scales to lots of users" is a very important and expensive feature to add to any product, so meeting that requirement will add massive drag to any programmer but comes with the benefit of dramatically increasing impact on real users. So if you're asking "how much software will they write?" the answer is much less, if you're asking "what will be the impact of that software on users?" the answer is much more.
The code written at a large company will generally be of higher "quality", in that much more effort will go into making sure the code has good security qualities, that it localizes well into every language, that it manages accessibility requirements for blind people, that it doesn't suffer from single points of failure, etc. etc. Whether this should be considered "more productive" is hard to say, it's critical if you want to scale code up to many users.
Bottom line: All those software tools, rules, collaborators etc. work to make your code work reliably and securely at scale at big companies, with the cost of slowing you down dramatically for actually getting software written.
------
One really interesting thing is the impact of Google Cloud or AWS. These internet services give a lot of the benefit of working at a large corporation to a software developer: instantly turn on complex and difficult to scale/manage services with great APIs you can develop on top of. The productivity multiplier as those services get better will only go up: cooperating via API is so much more efficient than cooperating via management, it's not even funny.
If I had to put forward a reason why we see a tendency to concentration for big tech companies like Google and Facebook, it's data advantage. The real advantage you have writing software at Facebook is access to that incredible private database of users and relationships, which makes it possible to write software there that you couldn't possibly write elsewhere. (Microsoft is more of traditional platform lockin with apps, Amazon I won't comment on as they are my employer,
The greatest difference is they work on different problems and it is impossible to separate value from use. Large firms face large problems and small firms small ones. Large firms can scale resources to the task, but small firms won't have large problems, and many large problems are simply too large and complex for them to handle. As a result I would say the output is proportional to value. with software just being necessary overhead.
It seems that so far the answer is that small firms are just much more productive in making small simple systems, but that big firms can be more productive at making big complex systems. So one reason that there are big firms is that there are big complex systems.
After some research i read about the surpisingly popular algorithim and this was the result http://inter-view.co.uk/hype/ or http://inter-view.co.uk
Attributing a percentage might be difficult, as developer productivity in general is not a well defined not does it have a commonly agreed on definition.
Developer productivity to should be mostly concerned with the outputs – which at the end of the day is still code – the quality of such outputs and the cost of those outputs.
For the last 7 years I been working for the same company which grew from the original 5 people team to a 100 team; and boy I can tell you that at least as far as I'm concerned we got a lot slower.
Put as a percentage I would say some tasks are now taking 200% more time to complete, and while is true that now we see larger projects and we have the ability to tackle much more complex tasks; is the simple ones, the trivial ones that I'm still shocked to see are taking too long to complete.
A larger organization faces a considerable amount of challenges to make sure knowledge transfer, communication and repeatable details are still achieved; a smaller team has the advantage of just turning left/right and asking for help or more information.
I've at times generated more output at small companies than large ones. Hard to say exactly by how much but maybe 200 to 300% more productive at a small firm. Mostly a matter of motivation: in big firms I am not much needed to be more productive and additional productivity has little marginal impact on the business so there's little reason to work harder than necessary. At a small firm my work is often necessary for the firm's continued existence, and the more the firm's existences hinges on my work the more productive I am. But then at small firms I've been no more or less productive than at big firms when my work didn't matter much. But to be fair this is all perceived productivity; I have no outside way to measure well how much work I did other than how much work it felt like I did.
I concur. I am a software developer at Google and when I write a highly-available and global service for millions of users I think I am thousands of percent more productive since many of the tricky problems (security, database, redundancy, backup) are already solved and one can focus on the business logic. I couldn’t do all that from scratch.
Just trying out something small could be delayed a bit by bureaucracy.
But today there are intense competition in the cloud space so key Google technologies like Spanner are available to anyone to rent. So perhaps this was more true 10 years ago.
A well known general rule for software development is that as you add programmers to a software development task, the marginal contribution of each programmer decreases, in large part due to communications and coordination overhead.
As a general case, programmers at small firms are currently able to use essentially the same tools as programmers at a large firm, so there is no inherent scalability advantage there.
In a small company, someone may not be able to specialize to the extent they could in a large company (separate QA groups, configuration management, production support, etc...), but that is only an advantage up to about 20-30 people, after that the benefits stop increasing.
"In the wild", I don't know of any software development teams which scale very far while working together. Looking at publicly available records, the Linux kernel is primarily the work of about 20 developers. There are lots more (10K?) with little tiny contributions, but they contribute way less each than what the top 20 do. For Windows 7, Microsoft purportedly had 23 feature development groups of about 40 people each, for less than a 1000 total, but I think you'd really count "40" as the number working on the "same" software.
So you can make more different products by adding development groups, but you rapidly reach the point of diminishing returns when trying to add developers to the same product. This would seem to imply that a small company of 40 developers would compete just fine with just about any scale of larger company, because they'd end up with a group of about 40 also working on the same problem.
You can consider "complex" software problems, but my experience is that complex software is typically a collection of simpler software which are then packaged together as an overall solution. Maybe someone out there makes a massive monolithic piece of software, but I don't know who would want to. There are advantages to buying a collection from one company to ensure interoperability, support and compatible upgrade cycles, but typically that still leaves room to compete for replacing components if the replacement is good enough and doesn't really speak to the question of developer productivity, just sales ability.
So in short, I'd agree with the others above and say based on experience, "Developers are likely 60% _less_ productive on average working at a big software firm", but that certain sales and packaging advantages keep them there for some software markets.
In games, there are some market-failing exceptions with large teams, but flagship (at the time) products like Sega's Sonic Adventure had a complete team of 30 people. Sonic Heros had a team of 19 people. There are lots of examples. Valve makes a major game engine (Source), lots of games, Steam, etc... with about 100 employees total.
I would argue that a very large source (the main source?) of the marginal productivity gain of working at big firms is the simple fact that big firms have access to a large base of people who are already willing to consume their outputs and do not need additional marketing.
Work at one of AppGooAmaFaceSoft. Probably around 50% - in smaller companies, depending on the company a good 50% of my time would go to (deployment, release, testing, security) and that burden is gone due to tooling that automates a lot of the manual work. There is also a gain that is harder to quantify that comes from having consistently more competent peers to review and assist with catching code problems.
Addendum - I'm not including the cost of understanding the large system i work on, which is of course much higher than at smaller companies. Given that i know the system im working on well, i get more time to focus on direct coding rather than on (deployment, release, testing, security). Also, to address comments others have made that they felt they were more productive at smaller firms. I would agree that I could 'code faster' at a smaller firm, when I was able to focus on coding, but that I got less time to do so because of the abovementioned busywork.
If you follow the money, Google is an advertising company. Techies are more attuned to its shiny technical products, but I suspect the shiny things have a lot to do with Larry & Sergey maintaining majority stake and rather than retiring when they hit it big, preferring to have armies of top-notch engineers to help them make fun shiny things.
But take away the advertising revenue and all that goes away. So perhaps your "magnet for good programmers" theory is correct, but less to do with prestige and more to do with companies that hit the jackpot with ads or taxis or whatever, and then use high salaries to attract a critical mass of sharp programmers to diversify.
(continuing). But perhaps what you mainly care about are big hypothetical futuristic firms that would compete against ems?
Perhaps the firms you're imagining would have limited AIs that do complicated tasks more efficiently than a human. So perhaps a firm solves the self-driving car problem. Or the babysitting problem (keep Junior or great-Grandpa from hurting themselves and provide basic needs). Or writing legal briefs or doing radiology.
In such cases, one key question is whether they can run on the customer's hardware. If a service today needs to query a petabyte datastore, it's going to run in the cloud and be owned by a big company.
Another barrier is IP. Perhaps that petabyte datastore requires sending cars out to map all the streets in the world, or an army of engineers to regularly tweak the neural net.
I'm less concerned about the IP in the core algorithm: usually the techniques end up in academic journals and patent applications. Openstreetmap.org works fine, and its rough edges improve over time, but it's hard to compete with google's map database.
So if we project today's supply market onto the future problem space, my prediction would be lots of open source stuff that lets anybody do some subset of tasks like language translation or image understanding. It took mankind decades to solve the problem, but the solution runs from a tidy library on your phone.
The messier problems like, say, maintaining a database of all the roads and places in the world, or the computationally expensive problems that have to run in a datacenter, would be the domain of the big firms.
(continuing) So what's with big firms, then?
One answer is that search and amazon and facebook have to be big complicated systems in the cloud. Amazon needs a big warehouse. Google's web index doesn't fit on your phone. Facebook puts all your friends in one place. So those are necessarily big firms.
But more lucrative and less savory are the walled gardens. Windows and Intel x86 dominated for decades because everybody's apps ran on it. Their biggest strength was also their biggest curse: backwards compatibility kept the customers captive but made it increasingly hard to change anything.
Apple's the biggest company in the world because it figured out how to vertically integrate the hardware supply chain, and produce a single model of phone that works well with the software.
Qualcomm is worth studying: they're cleaning up in the Android market because phones have a huge mess of radio stacks, each with tons of regulatory and IP constraints, and they've been consolidating the ability to put that in a single SoC.
So I guess my intuition is that a lot of the market for big software companies has to do with friction from IP, regulators, standards bodies, and hardware integration. When that friction can be overcome, some hacker in a basement takes care of it for everyone, and creates a public good that nobody pays attention to because it no longer appears on anybody's balance sheet.
> what fraction of software development is general as opposed to industry-specific, and how concentrated is this general software industry.
This is a hard question. Sounds like you already know enough about software to understand the significance of zero marginal cost. If I get everyone to standardize on metric hex cap screws, I can start a big firm producing them by the millions, and small firms can't touch my economy of scale. But software is weird: Dan Bernstein can singlehandedly write all the crypto for the entire world: http://www.metzdowd.com/pip...
Cloud software is a weird move toward *higher* marginal costs for the producer. It's easier for the producer to maintain and support, and opens the door to lucrative tracking and advertising. But it's much harder than just putting a tarball up on github.
A lot of the comments in this thread reflect that zeitgeist: scaling to a billion users means running complex cloud services, and here big companies have an advantage.
So that makes it easy to overlook the commoditized software infrastructure underpinning everything from big cloud services to your mobile phone.
Linux is a big project now with lots of contributors, but it's not owned by a big firm. Lots of the absolutely essential drivers and libraries -- the metric hex cap screws -- are maintained by single individuals in their free time.
So yes, there's a huge long tail of niche software easy for small firms to serve. But unlike mechanical industries, we shouldn't expect the commodity building blocks with huge volume to come from a big firm.
What if different size firms have access to different inputs? More specifically I'm wondering: might the prominence of some large software firms like Google or Facebook be partly due to their prestige, which enables them to attract the best programmers by bestowing onto them status that smaller firms just can't offer?
Right, in my last paragraph, my first proposition is that small systems have an advantage in cycle time.
The second proposition is perhaps harder to see: big companies have infrastructure optimized for big systems, and this makes it harder to build small systems.
The build, monitoring and deployment systems may each be a marvel of big system engineering, more complicated than a small company's entire operation. Small companies can't touch it, but nor are they forced to put up with their inertia and long-tail latency that make those systems painful for use in small projects.
I run a large tech organization, so I think about this problem a lot.
"Scales to lots of users" is a very important and expensive feature to add to any product, so meeting that requirement will add massive drag to any programmer but comes with the benefit of dramatically increasing impact on real users. So if you're asking "how much software will they write?" the answer is much less, if you're asking "what will be the impact of that software on users?" the answer is much more.
The code written at a large company will generally be of higher "quality", in that much more effort will go into making sure the code has good security qualities, that it localizes well into every language, that it manages accessibility requirements for blind people, that it doesn't suffer from single points of failure, etc. etc. Whether this should be considered "more productive" is hard to say, it's critical if you want to scale code up to many users.
Bottom line: All those software tools, rules, collaborators etc. work to make your code work reliably and securely at scale at big companies, with the cost of slowing you down dramatically for actually getting software written.
------
One really interesting thing is the impact of Google Cloud or AWS. These internet services give a lot of the benefit of working at a large corporation to a software developer: instantly turn on complex and difficult to scale/manage services with great APIs you can develop on top of. The productivity multiplier as those services get better will only go up: cooperating via API is so much more efficient than cooperating via management, it's not even funny.
If I had to put forward a reason why we see a tendency to concentration for big tech companies like Google and Facebook, it's data advantage. The real advantage you have writing software at Facebook is access to that incredible private database of users and relationships, which makes it possible to write software there that you couldn't possibly write elsewhere. (Microsoft is more of traditional platform lockin with apps, Amazon I won't comment on as they are my employer,
The greatest difference is they work on different problems and it is impossible to separate value from use. Large firms face large problems and small firms small ones. Large firms can scale resources to the task, but small firms won't have large problems, and many large problems are simply too large and complex for them to handle. As a result I would say the output is proportional to value. with software just being necessary overhead.
It seems that so far the answer is that small firms are just much more productive in making small simple systems, but that big firms can be more productive at making big complex systems. So one reason that there are big firms is that there are big complex systems.