This guest post is written by Auren Hoffman, the CEO of Rapleaf and an active angel investor. Auren argues that productivity gains among software engineers far outstrips pay increases. His advice? Stock up on engineers, it’s a competitive advantage. His advice reminds me of Joe Kraus‘ famous 2005 post that compared the cost of launching a startup in the nineties ($3 million) to one this decade ($100,000).
Productivity gains in software engineering are powering innovation. Everyone is more productive these days. This has been a consistent trend for at least the past decade, where productivity gains have been particularly strong within the business sector. According to data from the U.S. Bureau of Labor Statistics, today’s business industry workers are on average 30% more productive than their 1998 counterparts (productivity growth of roughly 2.6% per year).
Within the technology industry, productivity has increased more. Thanks to smartphones, improved search engines, better CRM software, and ever-increasing bandwidth, salesmen and marketers can find, receive and process information faster than ever.
The most dramatic gains, however, have occurred within software development.
Software engineers today are about 200-400% more productive than software engineers were 10 years ago because of open source software, better programming tools, common libraries, easier access to information, better education, and other factors. This means that one engineer today can do what 3-5 people did in 1999!
The advent of open source software makes engineers particularly efficient. One VP Engineering that I talked to gave me an anecdote about one module where they used open source files with about 500,000 lines of code and then wrote 7,000 lines of code to stitch it all together. Open source software is also free. In the company I was running in 1999, “software” was a huge budget line item – we had to buy databases, testing suites, libraries, and more. Today all that stuff is free … a start-up might spend more money on sodas for the office than it does on software.
We’re all familiar with Moore’s Law – that the power of computers doubles every 18 months. In my 15 years of software development, I’ve seen 5x-10x productivity gains in engineers. Which could mean that the productivity of a well-trained engineer doubles every five years. (note that this Law is much harder to prove than Moore’s Law – but potentially just as profound). That would mean that the productivity of an engineer is growing at roughly 14.9% per year! That’s fast … really fast … much faster than the 2.6% yearly gains than the population as a whole is making.
This means that today’s companies are able to do more software engineering and build more stuff with fewer people. But should they do more with less? It could be much more prudent for a company, especially for a small company, to do the opposite … and to double-down on engineering. You can use the productivity gains in software development as a strategic advantage and invest aggressively in engineers. First, doing so contributes the most to progress and also increases the chance for breakthroughs in innovation. Second, engineers – as opposed to salesmen and marketers – can often hit the ground running (assuming you have a good on-boarding system) and have a positive impact within a few weeks.
Alternatively, many large traditional companies might be able to get by with FEWER but DIFFERENT engineers. These companies might need to change their approach to engineering to take advantage of the new tools. The companies that can benefit from fewer engineers are likely ones that haven’t changed their technology platforms radically in the last ten years.
Although engineers contribute more to an organization than ever before, their pay – relative to other functions in a company – hasn’t followed suit. I’ve polled a few dozen companies and have found that over the last ten years, an engineer’s pay has held the same relative salary to marketing and sales. This is odd behavior … usually when something outputs more, its cost goes up. So why have engineers’ wages in the U.S. stayed constant relative to salespeople and marketers? Here are two contributing factors that lower demand:
- Off-shoring. Because of new technology and higher bandwidth, more companies are off-shoring their software development. But this does not fully explain the flat salary phenomenon since firms are also off-shoring sales and marketing (though to a lesser degree).
- Need for software engineers has decreased. Because software engineers are so much more productive then they were ten years ago, many firms are opting to hire fewer of them. If a company is not doing hard-core engineering, it actually needs fewer engineers as a portion of its total workforce than it did ten years ago. (I personally think this could be a big mistake … but I will get to that later).
Both the off-shoring and the decreased need for engineers has led to a lowering of the demand which has likely put a check on wages.
One problem, of course, is that measuring “output” of an engineer is a really hard thing to do (as opposed to the output of a salesperson) … so it is really hard to quantify the productivity gains. And even if you can measure output in engineering, it is sometimes hard to tie that to an increase in profitability.
And, like sales, the quality of engineers varies wildly. A great engineer is potentially 2-4 times more productive than a good engineer. Ben Ling from Google pointed out to me that some great engineers are massively compensated – because they tend to be the early hires at a company and get lots of stock (most of Google’s first 50 employees were engineers).
Let’s recap: The productivity of a software engineer has increased 2-3 times that of a marketing person in the last ten years. Yet their relative compensation has remained about the same. That means if you are a savvy company, you should stock up on engineers. In fact, you would want as many great engineers as you can get a hold of.
This engineering productivity boom will only increase and continue to create dislocation and creative destruction. While the extent of growth and industry makeover are hard to gauge, what is certain is that corporations relying on technology and engineering paradigms from the 1990s or before will find themselves hard-pressed to compete with the new and nimble movers.
(special thanks to Jonathan Hoffman, Michael Hsu, Ben Ling, Jeremy Lizt, Naghi Prasad, and Dave Selinger for their feedback and edits).
Interesting article Auren.
Do you have a link to the U.S. Bureau of Labor Statistics report?
I think main factors in right order are:
* Tools (Google Search, Eclipse IDE)
* Generation Gap (Newer generation is more interested in solving tougher problem than making money)
* Seamless acceptance of younger engineers even tough they have less experience. Even VC are now willing to take risk with fresh grads.
Please feel free to add more points.
Guest authors are also a great deal. Like most programmers today, they are willing to work for free.
SeekingAlpha.com built a great business model on the concept of free authors. As a contributing author for over three years, I can see how can work to the benefit of both parties, but only in some instances.
Too bad most of engineering is going to be outsourced from the US. American programmers can’t compete – the top performing 2% of China’s graduating class this year is bigger than the entire US graduating class. You guys obviously don’t read sites like http://www.anonboard.com to see the real side of working in the tech field.
Better yet. Fire yourself as the CEO and become a highly productive programmer.
good idea. not possible for most CEOs tho.
With this logic, because nuclear energy plants are more efficient than coal, we should start building ten times more. Hey, that actually makes more sense than hiring programmers.
Eh I feel like your viewpoint is “just throw more engineers at your problem” if Mythical Man Month taught us anything, it’s that that strategy often fails.
I thought he meant more engineers means more problems you can tackle. And therefore more income down the road.
More engineers is great to get more features quickly to the market.
But what is missing most of the time is the “glue” to adapt to the customer needs:
- Professional services engineers
- Documentation
- Engineers meeting customers to gather needs
- Internal and customer training
- Etc …
It’s one thing to have a theoretically great software, it’s another to have happy customers able to build on top of your software …
Some companies that higher too few of engineers seem to only be looking at them as if they were robots. People can get sick, have vacation days or anything that can let them miss work. Even though software engineers can have laptops, I doubt they want to be working constantly.
Very Interesting article, I hope I become a great engineer one day after I’m done with college.
Good post. We definitely get more done now with less engineers developing our own products then we did back in 1999 when we did client projects.
I thought it was well established that productivity of software engineers was impossible to measure? All the basic metrics: loc, number of bugs, features implemented, are prone to being gamed by employees.
Oh love that workstation photo – I wish I had that – not for the productivity gain, but for the coolness factor
Same here, with that setup I’d be six times faster than Andy Roddick!
@eric – i dont think hes talking about scaling engineers productivity in the cumulative sense. he is saying that every _individual_ engineer has a maximum theoretical output 5x more than 10 years ago.
so instead of saying “we can solve the problem 5 times faster by putting 5 times more engineers on it”
he is saying ” a single engineer can solve the same problem as 5 engineers could 10 years ago”
you are referring to a different problem : one that has to do with the effective “bonding” efficiency of teams.
he is also saying that now with the amount of tools and available knowledge, a “rockstar” engineer can be 3 times more productive than a “good” engineer with the same tools.
which leads to an important corollary : a single “rockstar” engineer today can achieve what a team of 20 engineers were required to do 10 years ago.
Interesting. I’m actually living this article.
Indeed, the productivity of AN engineer has gone up dramatically.
But the productivity of many engineers working together has not.
The more engineers you have, the more communication overhead there is. And all the improvements the author mentions just don’t help much with communication.
There’s a reason startups can build more with 5 engineers than a big company can with 50. And now, with the noted productivity improvements, you probably only need 3 instead of 5.
Great Point.
Actually, you are both right and wrong here. There are many tools that have come along to help cover the communication gap, and a good vc or pm will use those tools effectively and let the engineers do what they do best: great engineers always bounce ideas off of other respected engineers, in order to make better coding practices to gain more respect in the eyes of the community.
Open Source engineers do this often. Corporate engineers – not so much.
The part you are right at is the 5 versus 50 engineering part. If you are expecting all 50 to be working on the same project. Quite simply, one project rarely ever has enough work to keep more than 6-8 engineers busy at the same time: I’m including UI and backend in here – toss in qa or uat and you can get another 3-4 people on. You simply have too many bottle necks in the standard application to keep them all busy without someone going off on some tangent elsewhere. But if you took that 50 and made 6-8 projects or products with them .. Gold mine.
And that was the point of the article. Stock up on engineers and crank out a ton of product from the overflow. The more productive they become, the more products you can create at one time. It’s a no brainer that if you can get more products out the door than your competitor, you will gain top of the mind awareness faster, more people will look to you for new products, and you win the game.
how about the growth of salary?
In Asia we are still getting paid only peanuts
Companies would be smart to invest some of that excess productivity in quality. Except for best companies, the industry as a whole still has a dismal quality record, and the blame falls on unwillingness of both management and engineers to invest in the quality aspects of engineering. We are far from the defect-free mentality of Japanese automakers.
And no, I’m not and never have been a QA engineer.
I agree, I’ve seen the same results today in outsourcing to India as I did back in the mid-90s. And when push comes to shove, upper management releases the shit software.
I’m not sure I agree that engineers are 5 times faster today than 10 years ago because of open-source. I was building large client projects back in 1989-99 using open source with just 2 developers on my team. I still work on similar sized projects today and still use open-source libraries etc. I don’t feel that anything has really changed – certainly not 5 times faster ….. I only wish
Gooooooo engineers!
Hopefully companies read this report, even engineering positions are hard to find.
Who knows the biggest industry in the world whose foundation rely s on technology created before 1990??
healthcare will benefit greatly from the new generation of engineers through massive efficiency gains in the way health information is handled.
>>”So why have engineers’ wages in the U.S. stayed constant relative to salespeople and marketers? ”
Because the nature of sales/marketing (and therefore personnel) are usually better at positioning and selling themselves to potential enployers.
Ever so often, engineers – who are brilliant and focused on delivering productive, new innovation are parked into backoffice, development roles – and not (usually) client-fronting.
Its about driving perception. I’ve known great engineers, who also have an inherent talent(personality fit) for client-fronting sales/BD activities, who then go on to achieve great salary leaps …. but that’s only when they switch out of engineering roles into sales, client-fronting roles.
I know, ‘cos I’m living it myself. Engineering degree, 7yrs of engineering role and a mid-switch to front-line sales made all the difference.
No. Because programmers, like guitar players, are willing to offer their skill for free.
If you are got at something, never do it for free!
Don’t forget the additional and built in factors though; the best software programmers are 10-100x more productive than average. Be careful who you stock up on.
A Woz is worth a million offshore farm hands.
Wow! I love the workstation image!
Hmm, guess how much pixel all the monitor brings? I only see an engineer use 3monitor, only this time i can see engineer workstation using 5 computer monitors! Very cool.
I would recommend anyone entering college go for engineering. Much better to have the engineering base even if you want to be on the business side than having the business degree and having to deal with engineering.
hmm.. I think this misses the point entirely. Productivity gains are hardly a signal to hire more people surely? Productivity and infrastructure capabilities are now too far ahead of business models.
If you are a startup sitting on valuable last vestiges of cash, now is the time to sort out your value proposition, then hire to build that after.
As a software engineer, I was once shocked to learn that the average software engineer writes 5 lines of code a day. I guess they write 15 to 25 lines now.
After you consider time for testing, fixing bugs, changing requirements (client changes their mind and then changes it back) and code you have to throw away because you found a more elegant/efficient way to do the same thing, the 5 lines per day is not very shocking.
As @wattersjames said “A Woz is worth a million offshore farm hands”. That has been my experience, even just a team of average developers can up that lines-per-day figure dramatically compared to an off-shore crap-shack.
I was always confused by that statistic. I have writen code in many different languages and always achieved 60 to 100 lines a day (not flawlessly, but well structured.)
One line every 2 hours? Can these people walk and talk at the same time?
Those extreme statistics are averaged over everything involved with producing software, not just the coding, but debugging, design, documenting, and testing.
It’s because the best engineers are competing for the same jobs as cheap terrible ones who are willing to work for minimal pay. Companies often view engineers as commodities who will work incredibly hard for the joy of it. Why should a company pay you 20% more than the immigrant who works 100 hours a week and doesn’t complain, even if they’re horrible?
Because they are horrible?
Haha, yes “Because they are horrible”. And in the end, it’s not the management that hired them who will have to fix their off-shore (or as you put it immigrant) shmit and listen to the fools complain “why aren’t we on schedule”, it’s the ONE poor fool that may get 5% more who has to deal with all the crap.
Then again, that one poor fool is the one with the retarded goatee and the one wasting time on twitter.
How do you measure “productivity”? Usually this is what economists mean: $earnings per employee per hour.
So with the exact same piece of software, if the software market is much larger, your engineers will be more “productive” as well.
Thus much of this “productivity” you talk of is a mere function of more computers in the hands of people, more software to go with it, etc. as a result of the general expansion of IT over the last two decades.
I think unless you define productivity in a way different than this your whole premise (and thus the rest of your article) is dubious.
He defined productivity at the start by how cheap a startup is now versus how expensive it was in the 90’s (100k vs. 3m). You can easily take the cost of a product over a given time frame to calculate productivity gains. If you can create 30 projects for the price of one project 10 years ago, that’s a productivity gain of 30 times. I don’t care how you do the math per person or whatever that simple calculation shows immediate productivity gains.
By the way, my experience as a software engineer, and senior lead engineer at that, is there are normally 8 people involved in a single product from creation to launch and through marketing on the average. You take $100k divided by 8 people and you have a cost of $12,500 per person per product. Compare that to the $3m figure and and assume the same 8 people more (even though it was closer to 20-30: engineering was horribly bloated back then) and you have a cost of $375,000 per person per product. So you have a drop in costs of 30 times cheaper per person per product.
Now, since salaries are fairly flat over the time period, we can assume that it takes less time for each product to be made. Given that, we can assume the engineers are more productive. When you can fit 30 projects in the same time frame of 1 project before, you can claim that engineers are indeed far more productive than before.
The means of this productivity is also the engineers own doing. Open Source software is created by these same engineers to save time in future projects. So having engineers ensures you of more productivity gains through the nature of the engineers themselves. Go figure.
Quite interesting!
The idea of guest author is really amazing.
@gene tsai
although a single “Rockstar” engineer can annoy, irritate, condescend, bully and ultimately cause the resignation of a team of 20 “good” engineers.
And the only real difference between a “rockstar” engineer and a “good” engineer is the narcissism…
(do you consider yourself a “rockstar” engineer?)
While I agree that there is no justifiable reason for a brilliant engineer to be an asshole (I certainly won’t tolerate it), I have to say that it is incredibly plausible to have a case where one really awesome engineer is worth more than 20 engineers that are merely good by any metric you care to use. There are two big scenarios where this is the case:
1) The implementation is too dense to employ 20 engineers i.e. you can’t cut the work up into that many pieces. There are many kinds of software projects where the work does not distribute over more than a half dozen engineers at most. In those cases, productivity and output is solely a function of having the best possible people fill those handful of slots since you can’t throw headcount at it.
2) There are some software projects where “good” engineers are essentially incapable of delivering a competent solution — it is beyond their ken. Relatively few projects are like this, but when you come across one you might as well ignore all those “good” engineers, as all the productive output will come from the one or two brilliant engineers you hopefully have on the team. To be blunt, there are some software projects that merely “good” software folk can’t deliver on because it exceeds their skill in a way that book learning can’t fix.
Ironically, most of the prima donna software engineers I’ve worked with weren’t good, they just thought they were. The ultra-competent people are mostly down-to-earth, pleasant engineers to work with in my experience. I think the prima donna behavior is compensation relating to insecurity about competency.
As a general comment, the article is really assuming a certain kind of relatively low-grade software engineering; there are many types of exceedingly high-value applications where you will generate almost zero leverage from existing software tools. You can’t leverage productivity based on resources that you cannot use, though I recognize that there are many cases where the proliferation of open source software is an incredible boon to productivity. There is a non-trivial amount of software development that requires building most of the stack from the ground up. Any kind of genuinely new technology (as opposed to selling pet food on the Internet) often requires this.
That said, I agree that it is hard to underestimate the value of ultra-competent and experienced software people, particularly in the cases like the ones I describe above where you cannot leverage existing software. Stupidly good software engineers capable of cutting new ground are worth pretty much any price they ask in that market if you run the numbers, but as a practical matter this describes at most 1% of the software geeks I run across. Most of the software geeks that think this describes them aren’t, sad to say. An exaggerated sense of competence is an unfortunate affliction of many in the field.
This is true, but the problem you encounter with some investors when you are/have a very small programming team is that they don’t believe it’s possible to developp a software/web site without more people!
It’s unfortunate that more investors and upper-management don’t understand the simple concept of the “Mythical Man Month”. This is why you see so many companies going with off-shore development teams, the investors/management feel more comfortable if they have a whole shmit load of developers behind a project. Unfortunately, all that gives you is whole shmit load of crap.
All of the engineering productivity in the world doesn’t mean much if you aren’t able to monetize it.
And I’ve worked with, at or seen enough companies that had many productive engineers but still failed because the products didn’t address a market need or even if it did, the product wasn’t marketed/sold properly or the company didn’t deliver on their promises.
And all the productive engineers in the world can’t change that, as much as I wish they could.
Case in point is Google — Google prides itself on the number of engineers and Phd’s on the payroll, and yet we find that even Google was not able to build a video service that could compete with the market acceptance and growth rates seen by Youtube, so they acquired Youtube.
And this is even more evident in Google’s core business of search (which at last look was about 90% of their revenue). Initially, Google couldn’t find a way to monetize that traffic traffic. That is until, they turned to the competition and pilfered Overture’s key-word auction patents (originally Goto.com).
And even Google’s initial deal with Yahoo that put money in their pockets said more about Jerry Yang’s naivete/lack of business acumen and Michael Moritz’s shrewdness than about Google’s engineers’ number or productivity.
I love engineers. I love productivity. But engineering productivity in itself doesn’t make a profitable business.
As one of the founding members of Streetsine with an engineering background, I can attest to the validity of the claims make here. I’ve thought about this productivity gain vs remuneration issue independently and came to almost the same conclusions as this article!
In order to get the productivity gains suggested by the author, you have to have the right engineers, the right management, and the right goals for the company.
The best situation is for a creative person to recognize an opportunity that has become available. Something new and wonderful that can be built easily from existing modules.
The next step is having money thrown into the ring to hire the right engineers for the job. Not the same engineers that you always use. If you are going to start with 5 open-source modules, hire engineers that were instrumental in creating those modules. Pay them well and release them back into the wild when they are done.
Management would do well to cater to the rockstar engineers for that short time, feeding their belly and their ego as needed for the best performance.
The truth is that very few management types are willing to deal with a crew of hyper-creative type engineers. It’s too much risk. Managers get fired for taking risks.
It’s much safer for a manager to hire off-shore drudges at low cost, complain that their work is sub-standard, hand it over to some average local programmers for repair, and come out looking like a hero for ’saving’ the project.
Can you please post a link to both the USBLS report and to whatever source you have for the double claim about software engineers (200-400% more productive, and the reasons for it). I believe the general “30% over a decade” value; I’m highly sceptical of the 200-400% claim.
This industry shift from Waterfall to Agile / Scrum is also helping productivity: http://7thpixel...of-scrum-agile/
not that engineering talent isn’t critical, but these days for most consumer Internet startups the scarce resources aren’t programmers, but rather strong analytically-minded UX and marketing people (and I say that as a geek & former programmer).
it’s not impossible to code a basic webform, however you may very well fail even with rockstar coders if user experience blows / user adoption sucks, and your acquisition is poor.
Isn’t it possible that software engineering productivity is really an ebb and flow and not a steadily increasing value? It doesn’t seem like a stretch to say that Java, C#, et al. were originally a tremendous drain and even now much of what passes for productive work is really metawork. I especially have a difficult time with the article’s premise when quality is factored in. Perhaps we are all really just Wallys gettin’ paid for fixing bugs of our own making?
Great insights. For example, the number of resources needed to execute testing is declining per unit of software (e.g., function points, classes, etc.). Based on similar research conducted over the last several years, there is an exponential decline in the human effort needed to conduct software testing, mostly driven by better automation tools, use of virtualization (cloud computing), and stronger development frameworks (e.g., people are coding less and using prebuilt widgets).
Consistent with Hoffman’s observations, what took a test team of 35 people to do 10 years ago, only took 12-16 people 5 years ago, and takes 5-7 people now. The net result is that quality assurance in software-based systems is becoming less people intensive.
What is amazing, or counter intuitive, is that this declining trend is occurring in the presence of larger and more complex software systems. Systems are getting bigger (measures by lines of code) and more complex (by any measure, most notably interconnects) and tend to be more prone to errors (e.g., missing features, usability, improper coding, etc.). As such, more testing is often needed to ensure the systems operates according to specification.But it isn’t. Why?
What is implied in the research is that while complexity is going up, the capability of testing is driving down the need for people faster. This is something we have seen in other areas where software-based automation is used as well (consistency). In the end, it all makes sense.
apologies, image removed. not sure why auren didn’t ask.
great stuff. I’d like to read the Auren Hoffman follow-up post… Engineers becoming more sales oriented to sell what they coded. There’s also great old stuff on Summation
I think i’ve seen this somewhere before…but it’s not bad at all
As a software developer in my 20s, I have been noticing the growth in my own productivity over the past decade or so since I started programming.
Languages such as Python and Ruby are built with programmer productivity in mind and they come with extensive libraries. I still remember the days when I used to bang my head against the wall trying to program in Win32 and MFC. Java swing and Qt provided some respite, but they had their own drawbacks. These days, the .Net stack, MS Visual studio and MS Expression make cooking up ultra-cool distributed apps with kickass GUIs a *breeze*.
The corollary is that now is the best time to be in software development. The individual developer’s productivity is so high that we can conceivably create valuable IP on our own, stuff that would have taken an entire development team just years ago.
Carnets are a security that participating countries accept as a guarantee against the payment of Customs duties that may become due on goods temporarily imported under a carnet and not exported as required. ,