Numerous studies have found 10:1 differences in productivity and quality among individuals and even among teams. This blog contains Steve McConnell's thoughts about how to move toward the "10" side of that 10:1 ratio.
Add to Technorati Favorites Steve McConnell on Facebook
May 2007 - Posts
-
A comment I'm hearing with increasing frequency is "The job market is getting to be like the dot com era all over again. Developer salaries are increasing, and it's getting harder and harder to attract and retain good developers." Our May ECSE Meeting focused on the topic of "Compensation, Recruiting, and Retention," and so I used that as an opportunity to dig into the question of "Is it really 1999 all over again?"
The first question is, Is developer compensation increasing? I think quite clearly it is. The consensus raise for 2006 was about 3.5%-4.0%. The raises being budgeted for 2007 are more variable -- I've heard a low of 3.0% and a high of 6-7%. (These figures are all North American figures. Figures in India, Russia, and Eastern Europe can be very different.) But these are not the unprecedented raises we saw in 1998-1999; they're more incremental. Note too that a "budgeted raise of 5%" doesn't mean everyone will get 5%. People who are top performers will tend to get more than that. People who's compensation has gotten behind the market will tend to get higher raises too.
What is current developer compensation? Most of my data here is from the Seattle area. In the Seattle area, developer comp typically ranges from about $60K to about $120K, with very few people (less than 5% of the most senior people) making more than $120K. Fresh outs are being hired at $50-$60K in our area. East coast salaries tend to be similar, with higher salaries in more expensive areas (e.g., Manhattan). Salaries in less populated areas tend to be somewhat lower.
Bonuses. Most employers report annual bonuses of 5-15% for purely technical positions, with most companies paying closer to 5% than 15%. For very senior technical people and upper-level managers (i.e., Directors and VPs), bonuses can go higher than 15%, and in a few cases quite a bit higher. One company reported going as high as 50%. Most companies give higher-percentage bonuses to more senior people, although some don't differentiate on the basis of seniority.
Standard Benefits. We see a lot of commonality in benefits at this time. Fully-paid health coverage for employees seems to be standard among software employers. Partial coverage of dependent medical premiums seems to be common, with a few companies paying 100%. Starting vacation of 3 weeks is typical, with some companies offering only 2 weeks. Vacation increasing by an additional week after 5 years also seems to be typical. Vacation policies are almost always based on longevity with the company, and most managers have little flexibility in varying vacation policy.
Other Benefits. We discussed signing bonuses, stock options, stock grants, and other more elaborate perq's. Signing bonuses appear to be rare, still very much the exception rather than the rule. Most employers report that prospective hires are showing little interest in stock options. Apparently the memories of the dot com collapse are still fresh enough that many people would still rather have the bird in the hand of cash now rather than the bird in the bush of equity that might be worth a lot more later. Many companies sponsor occasional low-key "morale events" such as tickets to a baseball game, dinner out, pizza and beer at the office, and that kind of thing. Other more exotic and expensive perq's seem not to be reappearing at this time.
Hiring wars. A few companies reported losing key people, and in a few cases to "crazy offers that it just doesn't make sense to try to match." After quite a bit of discussion on this point at the ECSE meetings, the consensus seemed to be that these extreme compensation packages were more the result of a specific overactive recruiter than a symptom of the job market overall. Several companies in our area (Seattle) have reported losing staff to the most actively hiring companies (especially Google and Yahoo), but even in these cases the salaries offered were something like 20% higher, which doesn't seem to be symptomatic of any overheating in the job market. There have also been a few reported cases of very experienced people getting more than one job offer at a time, but again these seem to be the exceptions.
So, is it 1999 all over again? I think it clearly is not 1999 all over again. What we're seeing is healthy competition for top talent, which is really business as usual -- and business as it should be. We aren't seeing elaborate perqs -- no onsite massages, concierage service, nights out in limousines, and so on. We're not seeing hiring wars for average talent -- remember in 1999 we had hiring wars even for people whose only skill was writing basic HTML. We're not seeing huge equity grants or promises of ridiculous wealth in short time frames. People seem to have already forgotten how crazy 1998 and 1999 were. One ECSE member commented that people aren't currently "Expecting to work for five years and then be able to retire." My recollection is that people at that time expected to work for two years and then retire! The market was unbalanced in favor of employees -- to a degree that was unhealthy, because businesses were constantly confronted with unpredictable escalations in salaries, unexpected losses of key staff, uncontrollably high turnover. There was so much chaos in the job market that businesses had difficulty finding time to actually focus on their business.
In 2001 through 2002 or 2003 (depending on where in the country you were), we saw a job market that was unbalanced in favor of employers. There were so few open positions available, and the software personnel who had good jobs were so reluctant to change jobs, that even some qualified people had trouble finding work. That wasn't healthy either because it can cause talented, qualified people to leave the field.
Job Market 2007. What we are seeing today is that the best employees can command a premium, but they can't be unreasonable. Average employees can find jobs but probably aren't going to get multiple offers. The worst employees are going to struggle to find jobs at all.
That all sounds to me like a healthy, sustainable equilibrium -- a balance of power between employers and employees. I would be happy to see that balance continue for the foreseeable future.
Resources
-
-
-
-
-
Payscale's salary survey for senior software engineers / developers / programmers
-
"Orphans Preferred," Chapter from my book Professional Software Development on attributes including job prospects for software personnel: [ html] [pdf]
|
-
The May/June 2006 issue of IEEE Software published an interesting article that analyzed the estimation results of an extensive set of projects from Landmark Graphics. The author, Todd Little, analyzed the relationships between estimated outcomes and actual outcomes. Based on his data, he concluded that the 80% confident range of estimates did not reduce as the Cone of Uncertainty implies, but that the estimates continued to vary by about a factor of 3-4 for the remaining work on the project -- regardless of when in the project the estimate was created.
There are some interesting takaways from the article's data, and some of its conclusions are supported by the data, whereas others are not. The basic issue with the article's data is that it represents estimation accuracy as estimation commonly occurs in practice rather than
estimation accuracy when estimation is done well.
Figure 5 in Little's article is particularly interesting:
Figure 5 from "Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty."
Figure 5 shows a scatter plot of estimates created at different points in a project's duration. The scatter plot forms a near perfect cone--but only the half of the Cone that represents underestimation! There is only a tiny scattering of points that represent overestimation (those below the 1.0 line). As a view of estimation in practice, this is consistent with data my company has seen from many of our clients. It supports the conclusion that the software industry doesn't have a neutral estimation problem; it has an underestimation problem. (This is my conclusion, not the article's.)
The article's conclusions about the Cone of Uncertainty are less well supported. With reference to Figure 5, Little makes the observation that it forms a visual Cone, but only because the graph plots "estimated remaining duration" vs. "current position in the schedule." He points out that, since the duration remaining decreases as the project progresses, smaller estimation errors later in a project are not necessarily better. For the improved estimates to be accurate (i.e., for the Cone to be true), the estimates would need to be more accurate on a percentage-remaining basis, not just have a smaller absolute error. That analysis is all correct as far as I am concerned.
The article then goes on to point out that the relative error of the Landmark estimates didn't actually decrease, and concludes
"While the data supports some aspects of the cone of uncertainty, it doesn’t support the most common conclusion that uncertainty significantly decreases as the project progresses. Instead, I found that relative remaining uncertainty was essentially constant over the project’s life."
There are two reasons that this particular conclusion can't be drawn from Landmark's underlying data.
First, the article misstates the "common conclusion" about the Cone. As I’ve emphasized when I’ve written about it, the Cone represents best-case estimation accuracy; it’s easily possible to do worse—as many organizations have demonstrated for decades. Anyone who's ever worked on a project that got to "3 weeks from completion," and then slipped 6 weeks, and then got to "3 weeks from completion" again, and then slipped another 6 weeks, knows that uncertainty doesn't automatically decrease as a project progresses. The Cone is a hope, but not a promise. Little's data simply says that the estimates in the Landmark data set weren't very accurate. It's interesting to have this data put into the public eye, but it doesn't tell us anything we didn't already know. It tells us that software projects are routinely underestimated by a lot, and that projects aren't necessarily estimated any better at the end than they were at the beginning. That's a useful reminder, as long as we don't stretch the conclusions beyond what the underlying data supports.
The second problem with the conclusion the article draws about the Cone is that it doesn’t account for the effect of iterative development. Although it isn't stated in the published article, an earlier draft of the article, circulated on the Internet in mid 2003, emphasized that the projects in the data set were using agile practices, and in particular that they emphasized responding to change over performing to plan. In other words, the projects in this data set experienced significant requirements churn.
If the projects averaged 329 days as the article says, and if they followed agile practices as Little described in the 2003 version, there could easily be five to 10 iterations within each project. But the Cone applies to single iterations of the requirements-design-build-test process. For an analysis of the Cone of Uncertainty to be meaningful in a highly iterative context, the article would need to account for the effect of iteration on the Cone by looking at each iteration separately -- that is, by looking at 1-2 month iterations rather than looking at 329-day-long projects. The 329 day long projects are essentially sequences of little projects, so the way the Cone of Uncertainty applies in this case is that there isn't one big 329-day Cone; there are 6-12 1-2 month Cones instead. Unfortunately, the article doesn't present the iteration data; it presents only the rolled-up 329 data, which is unfortunately meaningless in terms of drawing any conclusions about how the Cone affects estimation accuracy over the course of a project.
The fact that requirements were treated in a highly iterative way also forces a reexamination of Figure 5. While it makes sense initially to treat Figure 5 as evidence of systemic underestimation, that conclusion can't be drawn either, because the requirements changed significantly over the course of the average 329 day project, and so whatever was delivered at the end of the project was not the same thing that was estimated at the beginning of the project, and that makes the early-project estimates and the late-in-the-project estimates an apples-to-oranges comparison, i.e., not meaningful.
Little makes an interesting comment at the end of the article that I think is a good takeaway overall. He points out that some of the variation in estimation accuracy was due to "a corproate culture using targets as estimates." Figure 5 might not provide a meaningful view of estimation accuracy, but it can certainly be interpreted as an indication that projects tend to set aggressive targets and then repeatedly fail to meet those targets. That's something we already knew, too, but it's good to have a reminder, and it's good to see that reminder supported with some data.
Resources
|
-
A reader of one of my books asked this question:
What is the impact of an improvement in response time on increased throughput? I develop many systems, and some have instantaneous response times, some have 10 minute response times, others have 4 or 5 hour response times. What are the threshholds at which response times affect throughput? Clearly going from 30 minutes to 30 seconds would be a big improvement. But would 30 minutes to 20 minutes also be a big improvement? [this has been paraphrased for clarity]
I think the key assumption in this statement is this: "Clearly going from 30 minutes to 30 seconds would be a big improvement." I suspect that sometimes the dynamic is actually the opposite of what the reader implied. With small changes in response time you can probably assume an increase in throughput. If response time improves from 10 seconds to 5 seconds, you can probably assume the users will get more work done.
But with large changes in response time (in either direction), I believe you will see users adopt offsetting behaviors that can outweigh any differences in response time. For example, years ago when computers were changing from batch processing to interactive processing there were some studies that tried to assess the improvements in productivity attributable to interactive systems. Surprisingly, I don't recall reading any study that found clear evidence of an improvement in productivity in the move from batch processing to interactive processing. Instead, the studies found that programmers had adapted to the long wait times in batch processing environments and filled their wait time with other useful activities.
It's like cooking in a microwave. If I heat up frozen vegetables on the stove, I can just throw them in the pan, turn the stove on low, and go do something else for 10 minutes. If I put them into the microwave for 40 seconds, I might very well stand in front of the microwave and wait for 40 seconds. The food cooks faster with the microwave, but I might actually get more done if I use the stove.
Fred Brooks made a similar point in a keynote address at ICSE '95. He commented that he wasn't sure there had been any real gains in productivity arising from the move from character-based displays to GUIs. He said, "I used to write a draft of a letter and then give it to my secretary to type the final draft. Now I type the draft myself, and then I spend 20 minutes making the fonts look nice!" In other words, more computing power doesn't necessarily mean more productivity.
In the famous IBM Chief Programmer Team project, one programmer wrote 83,000 lines of code in one year. This project took place in 1968. And the code was written in a batch processing environment. And on punch cards. This person had 8 other people arrayed around him in supporting roles, but that still works out to 9,200 lines of code per staff year for a business systems project. At Construx, we see lots of companies writing similar kinds of software that don't achieve 9,200 lines of code per staff year even 40 years later, even in highly interactive environments, even with radically better tool support, even on computers that are millions of times more powerful. Of course we see other companies writing code much faster, though we haven't yet seen any individual programmer who has written 83,000 lines of code in one year, no matter how the team is configured.
Productivity is only partly a function of how fast you go. Highly productive developers need to be aware of the difference between activity and productivity. The fact that you're busy doesn't mean you're getting work done. 10x developers focus on getting the actual work of the project done. They pay close attention to their experience to discern whether the work they're doing actually means more progress -- or just more motion.
References
|
|
|
|