Last week’s webinar on technical debt is now available for download.

I’ll be giving a free webinar on Managing Technical Debt on September 21, 2011 at 10:00 AM Pacific Time. Here’s the registration link: http://adtmag.com/webcasts/2011/08/construx-managing-technical-debt.aspx?partnerref=con5

Here’s a brief overview:

“Technical Debt” refers to delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules. Just like financial debt, some technical debts can serve valuable business purposes. Other technical debts are simply counterproductive. In this webinar, Steve McConnell explains in detail the different types of technical debt, when organizations should and shouldn’t take them on, and best practices in managing, tracking and paying down debt. You’ll gain insights into how to use technical debt strategically and how to keep technical and business staff involved in the process.

Our 2011 Software Executive Summit registration is now open. We have an early bird registration special of $1000 off through August 15. Register today!

I’ll be giving a free webinar on the 10 Deadly Sins of Software Estimation on April 28, 2011 at 10:00 AM Pacific Time. Here’s a link to sign up for it: http://adtmag.com/webcasts/2011/03/construx-10-deadly-sins-of-software-estimation.aspx?partnerref=con4.

Here’s the overview:

The average project overruns its budget and schedule estimates by 50-80 percent, but in practice little work is done that could truly be called "estimation." Many projects are scheduled using a combination of legitimate business targets and liberal doses of wishful thinking. In this talk, I will present 10 of the worst ways estimates go wrong and time-tested rules of thumb for dramatically improving estimation accuracy.

The Scrum Alliance Scrum Gathering conference is in Seattle this year, May 16-18, 2011. I’ll be giving the morning keynote on the second day. I’m excited to be able to share some of the details of Construx’s experiences helping organizations move to organization-wide Scrum. Here are the details about my talk:

KEYNOTE: THE JOURNEY TO ORGANIZATION-WIDE SCRUM

Scrum practitioners know what a successful Scrum project looks like. After a few successful pilot projects, many organizations struggle when they try to roll out Scrum more broadly. What does it take to roll out Scrum organization-wide? How much does by-the-book Scrum change, and what stays the same? Where do you draw the line between ScrumBut vs. necessary adaptation? What are the common stumbling blocks, and how do you overcome them? Who has to be involved?

In this presentation, award-winning author Steve McConnell shares a typical organization’s gap analysis between small-pilot-project- success and consistent-large-project-success. He describes the work needed from technical contributors, technical leaders, executive managers, and other business partners to implement Scrum. And he describes the path that has allowed Construx’s clients to realize the benefits of Scrum in larger teams, geographically distributed teams, and more complex organizations.

Here’s the info on the conference.

I’m working with Ryan Nelson and Mike Morris at University of Virginia to conduct a new survey of software estimation in practice. If you can take just a few minutes to answer some survey questions, this will help us get an update on the kinds of estimation practices people are actually using today.

Here’s the link to the survey: http://www.surveymonkey.com/s/uvaestimationsurvey

Thanks for your participation.

Readers have asked for years for electronic versions of my books, and I’m happy to say that electronic versions are now available for all of my Microsoft Press books.

• Software Estimation from Amazon.com in paperback or Kindle formats or from O'Reilly in various other Ebook formats (including pdf)
• Code Complete, 2nd Edition from Amazon.com in paperback or Kindle edition or O'Reilly in various Ebook formats (including pdf)
• Rapid Development from Amazon.com in paperbook or Kindle formats or from O'Reilly in various Ebook formats (including pdf)
• Software Project Survival Guide from Amazon.com in paperback or Kindle formats or from O'Reilly in various other Ebook formats (including pdf)

The title of this blog entry is an actual question. I really don’t understand why I didn’t like “The Social Network” more than I did.

Based on stellar reviews on Rotten Tomatoes and a good price on Amazon, I preordered The Social Network on blu-ray, which I watched Friday night.

This movie has many elements I should like. The screen play was written by Aaron Sorkin, who has written some of my favorite movies (A Few Good Men, The American President, Charlie Wilson’s War). The subject is the area I’ve spent my whole career in—the software industry, and it zeroes in on a specialty area that’s even more interesting: factors that contribute to success in startup environments. The movie steered clear of my biggest gripe about computer-related movies, which is focusing on hackers to the exclusion of everything else. The dialog was fast and witty. The acting was good across the board. Jesse Eisenberg portrayed Mark Zuckerberg as an intriguing, complex character. So why didn’t this movie work for me?

Roger Eberts’ review gives an interesting non-programmer perspective. Ebert says,

“It is said to be impossible to make a movie about a writer, because how can you show him only writing? It must also be impossible to make a movie about a computer programmer, because what is programming but writing in a language few people in the audience know? …

“The Social Network” is a great film not because of its dazzling style or visual cleverness, but because it is splendidly well-made. Despite the baffling complications of computer programming, web strategy and big finance, Aaron Sorkin's screenplay makes it all clear.”

I think what Ebert is saying (reading between the lines) is that computer programming is so inscrutable to most people, that ANY insight into how it’s done will be of interest to people – in part because 20-somethings can make billions doing it.

I think part of my issue is that I already knew that 20-somethings could make billions creating software. I’ve lived next door to Microsoft and Amazon my whole adult life and have been buying Dell computers as long as I can remember. This is not news to anyone I know. In the closing frames of the movie, when the final crawl tells the end of the story (“Facebook is worth $25 billion”) I felt like saying, “Was that really the point? EVERYBODY knew that before this movie came out.”

Another reaction I had was that, if we didn’t already know that Facebook was a true story and feel like it was giving us the inside view of how Facebook was created, the movie would not be interesting at all. The problem is, the most emotionally appealing parts of the movie are fictitious. The movie opens with a dialog between Zuckerberg and Erica, his soon-to-be ex-girlfriend from Boston University. Several times throughout the movie we see Zuckerberg reflecting wistfully about Erica. And in the final scene in the movie [spoiler alert], a lonely-looking Zuckerberg attempts to reconnect with Erica on Facebook. So there’s a dramatic symmetry from the beginning of the movie to the end, which is nice, except for the fact that it’s entirely fabricated. The was no girlfriend from BU, and in real life Zuckerberg has been with the same girlfriend from the year he began Facebook to the present.

Eisenberg’s portrayal of the intensely focused, socially awkward megalomaniac software genius was spot on. For people who haven’t previously been exposed to this type of person (like Roger Ebert), apparently that character portrayal was interesting enough to carry the movie. For me it wasn’t. I’ve spent the last 25 years around people like that, and to me that set of attributes is common enough to have become an archetype. Accurate portrayal of the archetype is a good place to start but is not in itself sufficient to make a great movie. I’m sure this archetype is more familiar to me than to much of the non-software public, and so maybe that’s the reason the movie was more interesting to other people than it was to me.

There were other story lines that  could have been interesting but that were left undeveloped. Eduardo Saverin, Zuckerberg’s college-buddy/CFO invests seed money but seems to lack the commitment to Facebook that many of the other players had. There is a potentially interesting exploration of the nature of entrepreneurial commitment, why some people have it and some people don’t, what it really takes to succeed as an entrepreneur, and whether in the end it’s all worth it. But that’s left unexplored.

The 3-way interactions between Sean Parker and Eduardo Saverin looked for awhile like they might develop into an interesting story. I was an expert witness in lawsuit that had a similar triangular between two founders and a third party, and the pathologies were fascinating. But the movie just scrapes the surface of those topics too.

There was also a potentially interesting investigation of, Who’s idea was Facebook really? What is the nature of intellectual property ownership? What gives someone the right to call something “my idea?” There was a subplot in which The Winklevoss twins hire Zuckerberg to create a Harvard-only networking site that was intended to be in the same social networking ballpark as Facebook. Zuckerberg goes off and creates Facebook instead of working on the Winklevoss’s project. That could have been used to explore the question of, What does it really mean to come up with an idea? The closest the movie gets to exploring these issues is a comment from Zuckerberg about “A guy who makes a nice chair doesn't owe money to everyone who has ever built a chair.”

The Winklevoss’s are drawn somewhat sympathetically, but as portrayed in the movie I think they represent capitalism at its worst. Their idea is half-formed. They have no ability to implement the idea themselves. The details they present to Zuckerberg get changed into something unrecognizable as he creates Facebook. If Zuckerberg had implemented their idea as they described it to him, it would have gone nowhere. The Winklevoss’s are obviously capable of doing hard work (they’re Olympic rowers), but they’re not capable of doing the specific type of hard work required to create Facebook. Nonetheless, they think that because they hired Zuckerberg to work on a social networking project that Facebook should be theirs. They hired him to create a nice chair. He never got around to creating their chair, and during the time he was supposed to be creating their chair he created an entirely new and different kind of chair that revolutionized the furniture industry. Does hiring him to build one kind of chair somehow give them a right to the amazing chair? The movie doesn’t explore that question.

Personally, I think that good ideas are a dime a dozen. The talent, energy and will to covert an idea into an appealing product is infinitely rarer.

In the absence of any story line that develops to any significant degree, what we’re left with is a lot of witty dialog that adds up to not much of a story, and an interesting character study of one of the 21st century’s well-known geniuses. That character study could provide interesting insights, except that the most interesting details were fabricated, which leaves us with no real insights after all. And that leaves us a movie that has very little to offer other than the fact that, as Ebert says, it was “splendidly well made.”  For me that wasn’t enough.

View it here (free membership required to view). 

Webinar - Managing Technical Debt

"Technical Debt" refers to delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules. Technical debt is inherently neither good nor bad: Just like financial debt, some technical debts can serve valuable business purposes. Other technical debts are simply counterproductive. However, just as with the financial kind, it's important to know what you're getting into.

In this one-hour webinar, noted author and software engineer Steve McConnell explains in detail the different types of technical debt, when organizations should and shouldn't take them on, and best practices in managing, tracking and paying down debt. You'll gain insights into how to use technical debt strategically and how to keep technical and business staff involved in the process.  

View it here (free membership required to view).

Here are the ECSE group’s Discussion topics for 2011:

	January	Job Market 2011: Compensation, Recruiting, and Retention Issues
	February	Organizational Structures
	March	Motivating Software Development Teams
	April	Issues for Software Development in Hardware-Centric Environments
	May	The Cloud's Impact on Software Development
	June	Scaling Agile
	July	Software Security Issues
	August	Summer Break
	September	Working with Software Business Partners
	October	Managing Maintenance and Sustaining Engineering
	November	Working with the Data Center
	December	Design-Driven vs. Engineering-Driven Software Product Development

In-person ECSE discussions in Bellevue are open to Seattle-area software executives who have multi-project span of responsibility and nominally oversee 100 or more technical staff. If you’re interested in participating, please contact me. Dial-in discussions are open to executives world-wide who have attended Construx’s annual Software Executive Summit or by invitation to qualified executives on a space-available basis. If you or an executive you work with is interested in either of these groups, please get in touch.

In response to my recent blog post on the research support for 10x productivity differences among programmers, Pete McBreen made the following comment: 

"One point in his article that McConnell did not address--programmer compensation does not vary accordingly. This is a telling point--if the difference is productivity can be 10X, why is it that salaries rarely fall outside the 2X range for experienced developers?" [emphasis in original] 

This is a good question. It’s timely because the Software Engineering Productivity group on LinkedIn has recently had a 130-comment discussion on the question of “Should pay be tied directly to productivity?” It's also a question that I wrestled with personally for about the first 10 years of my career. Indeed, it's part of the original reason I decided to became self employed back in 1989 and eventually founded my own company in 1996.

The Intuitive Version of the Question

I started my personal “10x compensation quest” from the point of view of, “I know I’m 3-5x as productive as the guy sitting next to me. Why am I not making 3-5x as much money?” Over a period of many years I found that this formulation of the question embodied several assumptions that were naïve or just plain wrong from a business perspective.

Six Myths of 10x Compensation

Let’s look at each of these myths of 10x compensation.

Myth 1. The guy next to me is getting paid what he’s worth. If I’m really 5x as productive as the guy sitting next to me, part of that is that I’m really productive, and part of that is the guy next to me is not very productive. Let’s say that we’re both first-year programmers and both making $65,000 (i.e., pretty typical first-year programmer comp in major markets these days). Me being 5x as productive as the other does not mean I should be making 5 * $65,000. It probably means something more like the other guy should be making $20,000 and I should be making $100,000. Part of the issue is that I’m underpaid a little; a bigger part of the issue is the other guy is overpaid a lot.

My personal observation is that average company has something like 20% of its programmers that aren’t contributing anything meaningful to the business and whose compensation should really be zero. In many companies, star performers’ low compensation is essentially subsidizing poor performers’ salaries.

Some people think, “If I’m a 10x programmer, I should be making 10x the average compensation.” But the 10x ratio is not 10x from best to average; it’s 10x from best to worst. If you think you should be making 10x what the worst programmers make, and the worst programmers should be making nothing, be careful what you wish for!

Myth 2. “Programming productivity” = “value to the business.” When someone says, “I’m 10x as good a programmer, therefore I should be paid 10x as much,” they’re assuming that their value to the business is based on their programming capability/contribution. That is part of the story, but not the whole story. Some mediocre programmers might be better at interacting with customers. Some might have better potential to move into management. Some might have less personal output but a wonderfully positive influence on overall team output. There are lots of other factors that influence “value to the business” besides raw programming output. 

Myth 3. High output should be rewarded with high salary. What’s mythical about this statement depends on understanding the difference between salary and compensation. When a business sets a salary (as opposed to a bonus – i.e., “fixed comp” vs. “variable comp”), the business is recognizing a person’s current contribution to the business, and it’s also making a calculated bet about the person’s contribution to the business in the future and over time. If I’m 5x as productive as the next guy this year, there’s no guarantee that I’ll be 5x as productive again next year. My motivation on the next project could be lower. I could be distracted by new girlfriend, new wife, new baby, parent’s health issues, personal health issues, new release of Call of Duty, etc. Most businesses won’t lower salaries except in extraordinary circumstances, so businesses are very conservative about increasing their employees salaries.

The same basic reasoning applies to salary offers to new employees. If I’m looking at a guy with a 20 year track record of uninterrupted outstanding performance, I’ll make one kind of a bet about his future productivity when I offer him a salary. If I’m looking at a guy with a 2 year track record, no matter how outstanding those 2 years have been, I’ll make a different kind of bet about his future productivity when I offer him a salary.

These issues are related to rewarding output with high salaries. Rewarding high output with high bonuses brings up different issues.  

Myth 4. Businesses try to pay people based on what they’re worth to the business. This is true only in the most approximate sense. I used to think that the ideal business would go through the thought process of, “This person is contributing $Y in value to our business, so we can pay them some fraction of Y and still make a profit.” That isn’t how businesses work. In my experience, businesses don’t make any attempt whatsoever to figure out on a person-by-person basis how much each person contributes to the bottom line.  At best, a business might go through an exercise of defining how much each job is worth (not each person) – but those exercises don’t account for whether the person in each job is a 1x performer or a 10x performer. For the reason, any analysis of “this job is worth Y” without considering the level of performance of the person doing the job is a meaningless exercise.

Since businesses almost never know what a specific person doing a specific job is worth, businesses generally pay people based on their market value, not on any calculation of their monetary contribution to the business. Businesses pay people whatever they need to pay them in order to attract the people they want to attract and retain the people they want to retain. Businesses aren’t going to pay any more than they have to to fill any particular job, and so they’re not going to pay above market if they don’t have to.  If a business can attract and retain a 10x developer for a 2x salary, that’s what it will do. 

As McBreen pointed out, the market salary structure for programmers is relatively flat. In the local executive discussion group I host, earlier this month we discussed “Job Market 2011,” including compensation issues. In our area (Seattle), starting salaries are running about $50-$65K for people with less than 1 year of experience. Top end salaries are in the $125-$150K range for senior, star technical performers with no management responsibilities. McBreen stated that he saw less than a 2x difference in compensation in his area. The situation is actually worse than he described. In our area, there is approximately 2.5x difference in the total range, including from most junior to most senior.

Myth 5. If a business wanted to pay based on productivity, it could measure individual productivity meaningfully enough to support its compensation decisions. As I discussed in a blog post in early 2008, measuring a 10x productivity difference in a research setting is one thing. Measuring productivity of specific individuals in a live production environment, on an ongoing basis, is a totally different challenge. The research measurement is possible and practical and has been done several times. The live, on-the-job measurement is subject to numerous “measurement error” issues that in my view make such measurements extremely impractical, if not downright impossible.

My first job after college I worked as a programmer at a company that tried to tie pay to productivity. We had a "billing hour bonus." There was a  formula for calculating the bonus, and there were lots of anomalies in the  formula. To get over the anomalies, the boss tweaked the formula almost every  month. By the time I left that company there were 17 variables in the formula  and almost all the programmers thought it was a joke. It mostly rewarded one guy who liked to work long hours, even though we all knew he was the least productive person there (both in terms of individual contribution and in terms of impact on others).

If we can’t meaningfully measure differences in performance, we’re left with more subjective assessments of programmers’ contributions to the business, which actually is how most businesses operate.

Myth 6. Companies don’t adjust pay for differences in productivity. Good companies do try to recognize differences in productivity. They have technical ladders that parallel their management ladders so that really good technical people can make salaries comparable to managers. Good companies attempt to pay based on very rough approximations of productivity over time. That's what different pay  grade levels are for, and that's what performance reviews are for.

Your reaction to that is might be something like, "Yeah right. Performance reviews.  Those are a joke. My boss doesn't really have any idea what I'm doing. I usually write my own review, or my boss just spouts generalities." That's right. Those are common problems with performance  reviews. And with that common experience, why would anyone think that "measuring productivity" would be any  more reliable than that? We have decades of experience via performance reviews that says it wouldn't be.

In Summary, Is All This “Right,” or is This Just the Way it Is?

I think it’s a little of both. I agree with the ideal of matching total compensation (not salary) to performance. But implementing that in practice is terribly challenging. The only practical way I can think of to truly tie pay to performance would be to move all employees to a contractor model and then pay them for well-defined pieces of work on a contract basis, with defined acceptance criteria and so on. I don't think that's practical, though, and it would undermine collaborative approaches like Scrum and also create some teamwork dynamics that I personally would rather not deal with. My overall conclusion is that paying for productivity  on any more than a very-rough-approximation basis is a panacea that cannot practically be achieved.

As I’ve commented previously, the discrepancy between capability differences and compensation differences does create opportunities for companies that are willing to hire from the top of the talent pool to receive disproportionately greater levels of output in exchange for only modestly higher compensation.

This is not the answer I expected to find when I began asking the question almost 25 years ago, but I can see the reasons for it. Gerald Weinberg describes a pattern he describes as "Things are the way they are because they got that way." I think this is one of those cases.

I’m excited about the webinar I’ll be leading on “A Technical Debt Roadmap.” It’s Tuesday, January 25, at 11:00 am Pacific Time. Check it out.

Here’s a description:

"Technical Debt" refers to delayed technical work that is incurred when technical short cuts are taken, usually in pursuit of calendar-driven software schedules.

Technical debt is inherently neither good nor bad. Just like financial debt, some technical debts can serve valuable business purposes. Other technical debts are simply counterproductive. However, just as with financial debt, it's important to know what you're getting into.

In this one-hour webinar, Steve McConnell explains in detail the different types of technical debt, when organizations should and shouldn't take them on, and best practices in managing, tracking and paying down debt. You'll gain insights into how to use technical debt strategically and how to keep technical and business staff involved in the process. Seats are limited, so sign up for this in-depth webinar today!

I recently contributed a chapter to Making Software (Oram and Wilson, eds., O’Reilly, 2011).  The purpose of this edited collection of essays is to pull together research-based writing on software engineering. In essence, the purpose is to say, “What do we really know (quantitatively based), and what do we only kind of think we know (subjectively based)?” My chapter, “What Does 10X Mean?” is an edited version of my 2008 blog entry “Productivity Variations Among Developers and Teams: The Origin of ‘10x’.” The chapter focuses on the research that supports the claim of 10-fold differences in productivity among programmers.

Laurent Bossavit published a critique of my blog entry on his company’s website in French. That critique was translated into English on a different website.

The critique (or its English translation, anyway) is quite critical of the claim that programmer productivity varies by 10x, quite critical of the research foundation for that claim, and quite critical of me personally. The specific nature of the criticism gives me an opportunity to talk about about the state of research in software development, my approach to writing about software development, and to revisit the 10x issue, which is one of my favorite topics.

The State of Software Engineering Research

Bossavit’s criticism of my writing is notable for the fact that it cites my work, comments on some of the citations that my work cites, but doesn’t cite any other software-specific research of its own.

In marked contrast, while I was working on the early stages of Code Complete, 1st Ed.,  I read a paper by B. A. Sheil titled “The Psychological Study of Programming” (Computing Surveys, Vol. 13. No. 1, March 1981).  Sheil reviewed dozens of papers on programming issues with a specific eye toward the research methodologies used. The conclusion of Sheil’s paper was sobering. The programming studies he reviewed failed to control for variables carefully enough to meet research standards that would be needed for publication in other more established fields like psychology. The papers didn’t achieve levels of statistical significance good enough for publication in other fields either. In other words, the research foundation for software engineering (circa 1981) was poor.

One of the biggest issues identified was that studies didn’t control for differences in individual capabilities. Suppose you’ve got a new methodology you believe increases productivity and quality by 50%. If there are potential differences as large as 10x between individuals, the differences arising from individuals in any given study will drown out any differences you might want to attribute to a change in methodology. See Figure 1.

Figure 1

This is a very big deal because almost none of the research at the time I was working on Code Complete 1 controlled for this variable. For example, a study would have Programmer Group A read a sample of code formatted using Technique X and Programmer Group B read a sample of code formatted using Technique Y. If Group A was found to be 25% more productive than Group B, you don’t really know whether it’s because Technique X is better than Technique Y and is helping productivity, or whether it’s because Group A started out being way more productive than Group B and Technique X actually hurt Group A’s productivity.

Since Sheil’s paper in 1981, this methodological limitation has continued to show up in productivity claims about new software development practices. For example, in the early 2000s the “poster child” project for Extreme Programming was the Chrysler C3 project. Numerous claims were made for XP’s effectiveness based on the productivity of that project. I personally never accepted the claims for the effectiveness of the XP methodology based on the C3 project because that project included rock star programmers Kent Beck, Martin Fowler, and Ron Jeffries, all working on the same project. The productivity of any project those guys work on would be at the top end of the bar shown on the left of Figure 1. Those guys could do a project using batch mode processing and punch cards and still be more productive than 95% of the teams out there.  Any methodological variations of 1x or 2x due to XP (or –1x or –2x) would be drowned out by the variation arising from C3’s exceptional personnel. In other words, considering the exceptional talent on the C3 project, it was impossible to tell whether the C3 project’s results were because of XP’s practices or in spite of XP’s practices.

My Decision About How to Write Code Complete

Bringing this all back to Code Complete 1, I hit a point early in the writing of Code Complete 1 where I was aware of Sheil’s research, aware of the limitations of many of the studies I was using, and trying to decide what kind of book I wanted to write.

The first argument I had with myself was how much weight to put on all the studies I had read. I read about 600 books and articles as background for Code Complete. Was I going to discard them altogether? I decided, No. The studies might not be conclusive, but many of them were surely suggestive. The book was being written by me and ultimately reflected my judgment, so whether the studies were conclusive or suggestive, my role as author was the same – separate the wheat from the chaff and present my personal conclusions. (There was quite a lot of chaff. Of the 600 books and articles I read, only about half made it into the bibliography. Code Complete’s bibliography includes only those 300 books and articles that were cited somewhere in the book.)

The second argument I had with myself was how much detail to provide about the studies I cited. The academic side of me argued that every time I cited a study I should explain the limitations of the study. The pragmatic side of me argued that Code Complete wasn’t supposed to be an academic book; it was supposed to be a practical book. If I went into detail about every study I cited, the book would be 3x as long without adding any practical value for its readers.

In the end I felt that detailed citations and elaborate explanations of of each study would detract from the main focus of the book. So I settled on a citation style in which I cited (Author, Year) keyed to fuller bibliographic citations in the bibliography. I figured readers who wanted more academic detail could follow up on the citations themselves.

A Deeper Dive Into the Research Supporting “10x”

After settling on that approach with Code Complete 1 (back in 1991) I’ve continued to use that approach in most of the rest of my writing, including in the chapter I contributed to Making Software.

One limitation of my approach has been that, with my terse citation style, someone who is motivated enough to follow up on the citations might not be able to find the part of the book or article that I was citing, or might not understand the specific way in which the material I cited supports the point I’m making. That appears to have been the case with Laurent Bossavit’s critique of my “10x” explanation.

Bossavit goes point by point through my citations and was not able to find the support for the claim of 10x differences in productivity. Let’s follow the same path and fill in the blanks.

Sackman, Erickson, and Grant, 1968. Here is my summary of the first research to find 10x differences in programmer productivity:

Detailed examination of Sackman, Erickson, and Grant's findings shows some  flaws in their methodology (including combining results from programmers working in low level programming languages with those working in high level programming languages). However, even after accounting for the flaws, their data still shows more than a 10-fold difference between the best programmers and the worst.

In years since the original study, the general finding that "There are order-of-magnitude differences among programmers" has been confirmed by many other studies of professional programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000).

The research on variations among individual programmers began with Sackman, Erickson, and Grant’s study published in 1968. Bossavit states that the 1968 study focused only on debugging, but that is not correct. As I stated in my blog article, the ratio of initial coding time between the best and worst programmers was about 20:1. The difference in program sizes was about 5:1. The difference in debugging was the most dramatic difference, at about 25:1, but it was not the only area in which differences were found. Differences found in coding time, debugging time, and program size all support a general claim of “order of magnitude” differences in productivity, i.e., a 10x difference.

An interesting historical footnote is that Sackman, Erickson, and Grant did not set out to show a 10x or 25x difference in productivity among programmers. The purpose of their research was to determine whether programming online offered any real productivity advantage compared to programming offline. What they discovered, to their surprise, was that, ala Figure 1, any difference in online vs. offline productivity was drowned out by the productivity differences among individuals. The factor they set out to study would be irrelevant today. The conclusion they stumbled onto by accident is one that we’re still talking about.

Curtis 1981. Bossavit criticizes my (Curtis 1981) citation by stating

The 1981 Curtis study included 60 programmers, which once again were dealing with a debugging rather than a programming task.

I do not know why he thinks this statement is a criticism of the Curtis study. In my corner of the world debugging is not the only programming task, but it certainly is an essential programming task, and everyone knows that. The Curtis article concludes that, “a statement such as ‘order of magnitude differences in the performance of individual programmers’ seems justified.” The (Curtis 1981) citation directly supports the 10x claim—almost word for word.

Curtis 1986. Moving to the next citation, Bossavit states that, “the 1986 Curtis article does not report on an empirical study.” I never stated that Curtis 1986 was an “empirical study.” Curtis 1986 is a broad paper that touches on, among other things, differences in programmer productivity. Bossavit says the paper “offers no support for the ‘10x’ claim.” But the first paragraph in section II.A. of the paper (p. 1093) summarizes 4 studies with the overall gist of the studies being that there are very large differences in productivity among programmers. The specific numbers cited are 28:1 and 23:1 differences. Clearly that again offers direct support for the 10x claim.

Mills 1983. The “Mills 1983” citation is to a book by Harlan Mills titled Software Productivity in which Mills cites 10:1 differences in productivity not just among individuals but also among teams. As Bossavit points out, the Mills book contains “experience reports,” among other things. Apparently Bossavit doesn’t consider an “experience report” to be a “study,” but I do, which is why I cited Mills’ 1983 book.

DeMarco and Lister 1985. Bossavit misreads my citation of DeMarco and Lister 1985, assuming it refers to their classic book Peopleware. That is a natural assumption, but as I stated clearly in the article’s bibliography, the reference was to their paper titled, "Programmer Performance and the Effects of the Workplace" which was published a couple years before PeopleWare.

Bossavit’s objection to this study is

The only “studies” reported on therein are the programming contests organized by the authors, which took place under loosely controlled conditions (participants were to tackle the exercises at their workplace and concurrently with their work as professional programmers), making the results hardly dependable.

Editorial insinuations aside, that is a correct description of what DeMarco and Lister reported, both in the paper I cited and in Peopleware. Their 1985 study had some of the methodological limitations Sheil’s discussed in 1981. Having said that, their study supports the 10x claim in spades and is not subject to many of the more common methodological weaknesses present in other software engineering studies. DeMarco and Lister reported results from 166 programmers, which is a much larger group than used in most studies. The programmers were working professionals rather than students, which is not always the case. The focus of the study was a complete programming assignment—design, code, desk check, and for part of the group, test and debug.

The programmers in DeMarco and Lister’s study were trying to complete an assignment in their normal workplace. Bossavit seems to think that undermines the credibility of their research. I think it enhances the credibility of their research. Which do you trust more: results from a study in which programmers worked in a carefully controlled university environment, or results from a study in which programmers were subjected to all the day-to-day interruptions and distractions that programmers are subjected to in real life? Personally I put more weight on the study that more closely models real-world conditions, which is why I cited it.

As far as the 10x claim goes, Bossavit should have looked at the paper I cited, not the book. The paper shows a 5.6x difference between the best and worst programmers—among the programmers who finished the assignment. About 10% of the programmers weren’t able to complete the assignment at all. That makes the difference between best and worst programmers essentially infinite – and certainly supports the round-number claim of 10x differences from the best programmers to the worst.

Card 1987. Bossavit says,

The 1987 Card reference isn’t an academic publication but an executive report by a private research institution, wherein a few tables of figures appear, none of which seem to directly bear on the “10x” claim.

The publication is an article in Information and Software Technology, which is “the international archival journal focusing on research and experience that contributes to the improvement of software development practices.” There is no basis for Bossavit to characterize Card’s journal article as an “executive report.”

Bossavit claims that none of the tables of figures “seem to directly bear on the ‘10x’ claim.” But on p. 293 of the article, Figure 3, titled “Programmer productivity variations,” shows two graphs: a “large project” graph in which productivity ranges from 0.9 to 7.9 (a difference of  8.8x ), and a “small project” graph with a productivity range of 0.5 to 10.8 (a difference of 21.6x). These “programmer productivity variation” graphs support the 10x claim quite directly.

Boehm and Papaccio 1988. I will acknowledge that this wasn’t the clearest citation for the underlying research I meant to refer to. I probably should have cited Boehm 1981 instead. In 1981, Barry Boehm published Software Engineering Economics, the first comprehensive description of the Cocomo estimation model. The adjustment factors for the model were derived through analysis of historical data. The model shows differences in team productivity based on programmer capability of 4.18 to 1. This is not quite an order of magnitude, but it is for teams, rather than for individuals, and generally supports the claim that “there are very large differences in capabilities between different individuals and teams.”

Boehm 2000. Bossavit states that he did not look at this source. Boehm 2000 is Software Cost Estimation with Cocomo II, the update of the Cocomo model that was originally described in Boehm 1981. In the 2000 update, the factors in the Cocomo model were calibrated using data from a database of about 100 projects. Cocomo II analyzes the effects of a number of personnel factors. According to Cocomo II, if you compare a team made up of top-tier programmers, experienced with the application, programming language, and platform they’re using, to a team made up of bottom tier programmers, inexperienced with the application, programming language, and platform they’re using, you can expect a difference of 5.3x in productivity.

The same conclusion applies here that applies to Boehm 1981: This is not quite an order of magnitude difference, but since it applies to teams rather than individuals, it generally supports the claim that “there are very large differences in capabilities between different individuals and teams.” It is also significant that, according to Cocomo II, the factors related to the personnel composing the team affect productivity more than any other factors.

Valett and McGarry 1989. Valett and McGarry provide additional detail from the same data set used by Card 1987 and also cites individual differences ranging from 8.8x to 21.6x. Valett and McGarry’s conclusion is based on data from more than 150 individuals across 25 major projects and includes coding as well as debugging. Bossavit claims this study amounts to a “citation of a citation,” but I don’t know why he claims that. Valett and McGarry were both at the organization described in the study and directly involved in it. And the differences cited certainly support my general claim of 10x differences in productivity among programmers.

Reaffirming: Strong Research Support for the 10x Conclusion

To summarize, the claim that Bossavit doesn’t like, is this:

The general finding that "There are order-of-magnitude differences among programmers" has been confirmed by many other studies of professional programmers (Curtis 1981, Mills 1983, DeMarco and Lister 1985, Curtis et al. 1986, Card 1987, Boehm and Papaccio 1988, Valett and McGarry 1989, Boehm et al 2000).

As I reviewed these citations once again in writing this article, I concluded again that they support the general finding that there are 10x productivity differences among programmers. The studies have collectively involved hundreds of professional programmers across a spectrum of programming activities. Specific differences range from about 5:1 to about 25:1, and in my judgment that collectively supports the 10x claim. Moreover, the research finding is consistent with my experience, in which I have personally observed 10x differences (or more) between different programmers. I think one reason the 10x claim resonates with many people is that many other software professionals have observed 10x differences among programmers too.

Bossavit concludes his review of my blog entry / book chapter by saying this:

What is happening here is not pretty. I’m not accusing McConnell here of being a bad person. I am claiming that for whatever reasons he is here dressing up, in the trappings of scientific discourse, what is in fact an unsupported assertion meshing well with his favored opinion. McConnell is abusing the mechanism of scientific citation to lend authority to a claim which derives it only from a couple studies which can be at best described as “exploratory” (and at worst, maybe, as “discredited”).

Obviously I disagree with Bossavit’s conclusion. Saying he thinks there are methodological weaknesses in the studies I cited would be one kind of criticism that might contain a grain of truth. None of the studies are perfect, and we could have a constructive dialog about that. But that isn’t what he says. He says I am making “unsupported assertions” and “cheating with citations.” Those claims are extreme and unfounded. Bossavit seems to be aspiring to some academic ideal in which the only studies that can be cited are those that are methodologically pure in every respect. That’s a laudable ideal, but it would have the practical effect of restricting the universe of allowable software engineering studies to zero.

Having said that, the body of research that supports the 10x claim is as solid as any research that’s been done in software engineering. Studies that support the 10x claim are singularly not subject to the methodological limitation described in Figure 1, because they are studying individual variability itself (i.e., only the left side of the figure). Bossavit does not cite even one study—flawed or otherwise—that counters the 10x claim, and I haven’t seen any such studies either. The fact that no studies have produced findings that contradict the 10x claim provides even more confidence in the 10x claim. When I consider the number of studies that have been done, in aggregate I find the research to be not only suggestive, but conclusive—which is rare in software engineering research. 

As for my writing style, even if people misunderstand what I’ve written from time to time, I plan to stand by my practical-focus-with-minimal-citations approach. I think most readers prefer the one paragraph summary with citations that I repeated at the top of this section to the two dozen paragraphs that academically dissect it. It’s interesting to go into that level of detail once in awhile, but not very often.

References

Boehm, Barry W., and Philip N. Papaccio. 1988. "Understanding and Controlling Software Costs." IEEE Transactions on Software Engineering SE-14, no. 10 (October): 1462-77.

Boehm, Barry, 1981. Software Engineering Economics, Boston, Mass.: Addison Wesley, 1981.

Boehm, Barry, et al, 2000. Software Cost Estimation with Cocomo II, Boston, Mass.: Addison Wesley, 2000.

Boehm, Barry W., T. E. Gray, and T. Seewaldt. 1984. "Prototyping Versus Specifying: A Multiproject Experiment." IEEE Transactions on Software Engineering SE-10, no. 3 (May): 290-303. Also in Jones 1986b.

Card, David N. 1987. "A Software Technology Evaluation Program." Information and Software Technology 29, no. 6 (July/August): 291-300.

Curtis, Bill. 1981. "Substantiating Programmer Variability." Proceedings of the IEEE 69, no. 7: 846.

Curtis, Bill, et al. 1986. "Software Psychology: The Need for an Interdisciplinary Program." Proceedings of the IEEE 74, no. 8: 1092-1106.

DeMarco, Tom, and Timothy Lister. 1985. "Programmer Performance and the Effects of the Workplace." Proceedings of the 8th International Conference on Software Engineering. Washington, D.C.: IEEE Computer Society Press, 268-72.

DeMarco, Tom and Timothy Lister, 1999. Peopleware: Productive Projects and Teams, 2d Ed. New York: Dorset House, 1999.

Mills, Harlan D. 1983. Software Productivity. Boston, Mass.: Little, Brown.

Sackman, H., W.J. Erikson, and E. E. Grant. 1968. "Exploratory Experimental Studies Comparing Online and Offline Programming Performance." Communications of the ACM 11, no. 1 (January): 3-11.

Sheil, B. A.  1981. “The Psychological Study of Programming,” Computing Surveys, Vol. 13. No. 1, March 1981. 

Valett, J., and F. E. McGarry. 1989. "A Summary of Software Measurement Experiences in the Software Engineering Laboratory." Journal of Systems and Software 9, no. 2 (February): 137-48.

Construx is looking for a trainer/consultant. Construx has a fantastic staff and unmatched benefits. For the well qualified person who wants to do excellent work in a highly stimulating environment, it is a dream job -- which is why we've been recognized as the Best Small Company to Work for in Washington State twice.

Here's the official job posting:

---

Construx is seeking an experienced software engineer to provide training and consulting services with an initial emphasis on training ("Technical Service Provider (TSP)"). Deep software development experience is required, as is broad and deep knowledge of software development literature. Strong preference will be given to candidates with extensive training and/or public speaking experience. Candidates must have "leadership" level capability in at least three of the following knowledge areas:

• Software Project Management
• Software Requirements
• Software Design
• Software Construction
• Software Test
• Software Quality Assurance
• Software Maintenance
• Software Tools and Methods
• Software Configuration Management

Detailed Duties

Seminar Delivery. Deliver software engineering seminars to working software professionals at our Bellevue, Washington training facility and at client locations in North America and worldwide. For a list of current seminars, see our Course List by Job Title. Most seminars are 2-3 days in duration. The new TSP will qualify to teach 2-3 different seminars within the first year. Most Construx TSPs eventually qualify to teach 5-10 or more different seminars.

Seminar Development. Develop new seminars to complement Construx’s list of current seminars. Modify existing seminars to respond to client needs, incorporate advances in methods, and match personal preferences of the TSP.

Consulting. Provide consulting support to training clients as needed. Initially, consulting is expected to make up only a small part of this position.

Travel. Travel is required and ranges from 25% to 75%. Exact amount of travel within this range will depend on business demands and will be decided by mutual agreement between the TSP and Construx. Most Construx TSPs travel between 25%-50%.

Support for Sales Process. Work with Construx sales staff to discuss Construx offerings with new and existing clients, review proposals, and so on.

Ongoing Training and Professional Development. Participate in ongoing training via reading, attending Construx seminars, attending outside seminars, and presenting at and participating in conferences.

On Location in Bellevue Office. This position is homed at Construx’s office in Bellevue, Washington. Construx permits telecommuting as job demands allow, but normally expects that TSPs are in the Bellevue office at least four days per week when not traveling. 

Inclusive Job Definition. Over time, Construx will always work to maximize the match between a person’s interests and the available work. At any given time, however, Construx requires employees to be flexible in keeping the company running. At times this can include activities as mundane as stocking the soda machine, sweeping the floor, unjamming the printer, and so on. As a small company sometimes the job description is "Whatever needs to be done by whoever is available to do it."

Requirements and Qualifications

Software Development Experience. A minimum of 10 years of broad and deep experience in software development is required.

Training Experience. Must have excellent interpersonal verbal skills, presentation skills, and writing skills. Strong preference will be given to candidates with extensive training and/or public speaking experience.

Education. A four-year degree from an accredited university strongly preferred. Broad and deep knowledge of current software development literature is also required. "Leadership" level understanding of at least three of the following knowledge areas is required: Software Project Management, Software Requirements, Software Process, Software Maintenance, Software Design, Software Construction, Software Test, Software Quality, Software Configuration Management, and Software Tools and Methods.

Certifications. Certification is not required. Certifications of CSDP, PMP, Certified Scrum Trainer, Certified Scrum Coach, and Certified Scrum Practitioner are a plus.

Toolbox orientation. Construx is not pro-Agile, pro-Scrum, pro-waterfall, pro-CMMI, pro-modeling, pro-PMI, or pro-anything else. Construx works with an incredible diversity of companies facing an amazing range of software challenges. Construx TSPs must have a balanced view of software development practices, viewing the universe of software development practices as different tools that are better suited or worse suited to specific jobs. Different TSPs will have different focuses, different interests, different backgrounds, and different areas of expertise. We do not expect every TSP to be enthusiastic about every kind of software practice, however we do require every TSP to be knowledgeable and open minded about the contributions that different kinds of practices are able to make in different contexts.

Presentations. A record of conference presentations is a strong plus.

Publications. A record of publications in refereed journals and/or popular trade publications is a plus.

Interpersonal Skills. Require the ability to work well in a team; ability to foster partnership relationships, active communicator.

Service Quality Orientation. Must be willing to pursue the highest possible levels of service quality, to measure personal service quality in ways that are visible to management and to peers, to discuss service quality, and to continually improve service quality.

Entrepreneurial. Outstanding self-management, project management, and time management skills and the ability to multi-task and manage competing priorities effectively. Must be willing to accept a significant portion of compensation as variable, based on performance.

Compensation

Compensation is base plus bonus. Base is approximately industry median with significant bonus potential. Construx has paid bonuses of 50%-100% or more depending on billable work. Amount of billable work depends on service quality, number of classes taught, willingness to travel, and other factors. Construx's goal is to allow each TSP to strike the personal balance he or she desires between compensation/travel/work, and personal life.

Supervisory Responsibilities

None at present.

Interaction

This person will interact with customers, other TSPs, sales staff, department heads, and administrative support personnel.

Company and Work Environment

Founded in 1996, Construx's corporate mission is to Advance the Art and Science of Commercial Software Engineering. Construx provides training and consulting services in the area of software development best practices. Our clients are who’s who of Fortune 500 companies, technology leaders, and selected smaller companies.

In June 2007 Construx was named the Best Small Company to Work For in Washington State by Washington CEO magazine, and in Summer 2008 Construx was again named the Best Small Company to Work for in Washington State by the Puget Sound Business Journal. Construx emphasizes hiring talented staff who are committed to making consistently excellent contributions within a team environment.

Hiring only the best people enables us to offer a work environment and benefits that are second to none. Benefits include:

• Private offices with office decorating budget
• Laptops
• Flexible schedule (as permitted by work demands)
• Business casual dress
• 30 days of paid time off per year plus holidays (including 4 floating holidays)
• Strong company commitment to maintaining balance between work and personal life
• 401K with 100% match to 10% of base salary
• Profit sharing
• Stock options
• Training as needed
• Family medical plan
• Family dental plan
• Family vision plan
• Long term disability coverage
• Company events at the Salish Lodge, the Herb Farm, Willows Lodge, Leavenworth, Chelan, and comparable locations
• Free all-company lunches every Friday
• Free beverages
• Staff that enjoys doing excellent work and enjoys working with each other

Contact Us About This Position

Email: resume@construx.com
Fax: 425.636.0159

 

The 2010 Executive Council for Software Excellence (ECSE) meeting topics have been announced. They are:

January	Optimizing for Innovation
February	Accelerating Organizational Change
March	Successful Leadership in Software Development
April	Managing the Release Process
May	Managing "Core" Development (aka "shared services" or "foundations")
June	Succeeding with Crunch Mode Projects
July	The Business of Software Development
August	Summer Break
September	Working Effectively with the Executive Team
October	Managing Technical Debt
November	Agile Development at the Enterprise Level
December	Managing Global Development

The ECSE meets in-person in Bellevue, Washington the second Monday of each month from 5:00-7:00 pm, Pacific Time and via teleconference the Friday following the second Monday of each month from 12:00 noon -1:00 pm, Eastern time (9:00-10:00 am Pacific time).

ECSE members are software executives and senior managers who have multi-project responsibility, typically with staffs of 100+. You can see more details at the ECSE Website (you'll need a free login to access this website).

If you're interested in joining the group, please contact me.

A reader of our 2008 Classic Mistakes White Paper made the following observation:

I work in the Aerospace/Defense industry and have read your article called Software Development's Classic Mistakes 2008 dated July 2008. I am most interested in questioning the results of your most damaging classic mistakes overall that is tabulated in Table 8. I have read that up to 70% of project failures can be attributed to incomplete and poorly communicated requirements. Furthermore, the root cause of more than 50% of all errors identified in projects are introduced during the requirements analysis phase.

Could you please shed some light as to why the results of your study don't cite mistakes that are attributed to requirements? Is this embedded in one or more of the tasks or is this a non-issue?

The reader is correct that multiple industry studies have found that requirements problems are the most common source of project challenges, so I can see why our results might seem anomalous.

The fact is that people who took our survey were given the chance to rate requirements as severe classic mistakes, and they just didn't. We included several classic mistakes in our study related to requirements:

• Feature creep
• Shortchanged upstream activities
• Lack of user involvement
• Unclear project vision
• Requirements gold plating

Of these requirements-related mistakes, feature creep made the overall top 10 list (at #7). It was also the 6th most commonly reported mistake. None of the other requirements-related mistakes made the top 10 list for frequency, and none of them including feature creep made the top 10 list for severity.

Based on our consulting experience I am not that surprised to see non-requirements mistakes percolate to the top of the classic mistakes list. Some of the other studies I've seen didn't offer the option to choose some of the problems we listed in our survey, which means their survey respondents didn't have the chance to rank them higher than requirements problems.

Some studies I've seen survey only project managers, which could give a one-sided view of which mistakes are most common. And many of the surveys I've seen focus only on business systems projects (most notably, the Standish Group survey), whereas our data set was for a broader set of projects.

We've also found in many cases that requirements problems are symptoms of other issues, such as overly optimistic schedules (leading to shortchanging requirements), unrealistic expectations (same issue), short-changed QA (don't detect requirements problems until late), etc.

We don't have a classic mistake called simply "bad requirements" or anything comparable to that. Maybe we should add that.

Classic Mistakes Update

We're updating our Classic mistakes survey in 2010. Help update these results, and take the survey!

Related Articles

• Construx's classic mistakes white paper 2008
• My blog summary of our classic mistakes survey results
• Take the 2010 Classic Mistakes survey!

One benefit of my job is that I get to talk to people from hundreds of companies every year, and the people I work with talk to even more people. In recent discussions I've seen a disturbing trend emerging -- disturbing because it's so common and because the effects are so easily predictable.

With the economic challenges many companies are facing, many companies have imposed travel restrictions that in practice are working out to "zero travel." I understand the value of this as a general cost containment measure. However, we are seeing increasing numbers of companies that have also applied this travel restriction to their offshore projects -- meaning no one from their domestic group can spend time with their offshore groups, and no one from the offshore groups can travel to their domestic locations.

The problem is this: Offshore development is challenging enough when you do everything right. Face-to-face time is an essential part of successful multi-site development. Video conferencing, web conferencing, etc. are all useful supplements to face-to-face time, but there is no good substitute for meeting the people you work with in person, meeting their families, having dinner and drinks together, playing soccer together -- that is, getting to know the other people as human beings. 

When crunch time hits, teams are a lot more effective when they're working with their "friends in another country" than when they're working with "those stupid offshore idiots who never understand our designs or requirements."

One executive put it this way: "The half life of trust is 6 weeks," where trust is based on face-to-face communication. As face-to-face time drops, the consequences are easy to predict:

1. Significantly increased communication mistakes
2. Problems in requirements, designs, test cases, etc. due to #1
3. Significantly increased defects due to #1 and #2
4. Increased friction between domestic vs. offshore groups due to #1-#3
5. Reduced trust due to all the above
6. More "us vs. them" thinking
7. Less ability to work through problems as they arise due to #1-#6
8. Overall reduction in effectiveness of the offshore operation due to all the above

The overarching issue here is that the consideration that most commonly causes companies to go offshore is cost reduction, so it's not hard to understand why companies that go offshore to reduce costs would also eliminate travel in these challenging times for the same reason. Unfortunately that combination creates a "perfect storm" of factors that over time will render offshore development unworkable. 

It's been a few years since I've seen a widespread pattern like this where the consequences were both so damaging and so predictable. In all the companies Construx has worked with, I can't think of a single case in which offshore development has been successful for a company that didn't commit to significant face time between teams at different sites. If the current travel moratorium lasts 3-6 months, most companies will probably be able to recover. If it lasts much longer, I think we'll start to see companies "reevaluating their offshore strategies" -- and overlooking the fact that offshoring stopped working when their people stopped traveling.

Construx has developed the State of the Practice Survey with the goal of better understanding which software practices really work, which really don't work, and identify trends in practice adoption.

Survey participants will receive a summary report of the findings later this year in advance of the published report.

I hope you will share your views about the state of the practices in your organization. No one outside Construx will see any of the raw data, and information you share will be presented only in the form of summary statistics.

I invite you to participate in the survey: https://vovici.com/wsb.dll/s/10431g3c3a5

UCU4HFPHZY2R

I now have a public Facebook page at http://www.facebook.com/n/?pages/Steve-McConnell/198720075270&mid=8a4602G316afb94G1ae8a37G4c.

 

I plan to use this page for small scale blog entries, updates on what I'm reading, announcements, and so on.

I'll be giving a free webinar tomorrow at 10:00 am Pacific time on the 10 Deadly Sins of Software Estimation. You can sign up here:

http://www.sdtimes.com/content/webinars.aspx

Here's the full announcement:

The average project overruns its planned budget and schedule by 50%-80%. In practice, little work is done that could truly be called "estimation." Many projects are scheduled using a combination of legitimate business targets and liberal doses of wishful thinking. In this talk, award-winning author Steve McConnell presents 10 of the worst ways estimates go wrong, and presents time-tested rules of thumb for dramatically improving estimation accuracy

I receive several requests a year to sit on various advisory boards, and I always say no--I just don't have the time. Last year I received a request I couldn't refuse from Charles Seybold, Bruce Henry, and Jason Carlson at LiquidPlanner. I had known Charles and Bruce when they were at Expedia and thought highly of their work, but the real appeal was the tool they were building.

They started with the vision of an online project planning tool that would include probabilistic scheduling, in a sense a more flexible, on-line replacement for Microsoft Project. As LiquidPlanner took shape, their tool concept grew far beyond a Project replacement. The name of their tool is apt: Liquid Planner has created an online project community that supports work in modern-style projects and managing them far better than any other tool I've seen.

Key features of the tool include:

• Online tool can be used by individual contributors at different development sites
• Individual contributors enter and update their own estimates, priorities, dependencies, and so on; the tool calculates the overall project plan
• Dashboard allows a "big picture view" of the whole project
• Individuals can view their own tasks and the tasks lists for other team members
• Task-level estimates can be entered in ranges; LP computes the overall project "landing zone"
• Integrated email and issue tracking
• "Workspace chatter" allows project members to collaborate on tasks, ask questions, throw out ideas, and so on, all the while maintaining discussion threads for future reference. A wiki-like area allows for central storage of reference information about the project
• Time tracking is integrated

LP recently released LiquidPlanner 2.0, and I think this release achieves the elusive goal of synergy--where the interactions between the different parts add capability that goes well beyond each part considered individually.

For example, we've seen time tracking fail in many organizations because it's a standalone activity whose purpose has been poorly communicated, and many people just refuse to do it. In LP, time tracking is integrated with estimation, scheduling, and the online project community. There's no task-switching overhead to enter time into a different tool, and the purpose is much clearer (entering actuals against estimates). Time tracking becomes a seamless part of working on a project.

Another example is bottom-up task estimates. In other tools, individuals create estimates for their own work, perhaps in a spreadsheet, give them to their manager, who re-enters them into Project or perhaps a different spreadsheet. The manager tracks progress by going around and asking people what they've completed. Estimation is done in one environment, planning is done in another environment, tracking is done in a third environment, and so on. In such an environment estimates often get of date; we've even seen estimates entered post facto, i.e., after the work has been done. In LP, estimating the work, organizing the work, tracking the work, and commenting on the work are all integrated into the same tool.

LP becomes a project ecosystem in which it's just easier for the team to stay in the environment than to move out of it, and have the team working in a planning-aware environment produces all kinds of benefits.

Liquid Planner calls all this Social Project Management. In essence it simultaneously democratizes the project management task by facilitating greater contributions from all team members while empowering project managers with richer, more detailed, and more current project information. LP offers a 30-day free trial, and I encourage you to check it out.

• Liquid Planner Home Page
• Feature Summary
• Screen Shots

After listening to doom and gloom economic reports for the past few months, we decided we would try to do something to brighten our little corner of the world. Here's our official press release about it:

Construx Software has designated 25% of its public seminar seats free of charge to software workers who have been laid off. Construx seminars help software professionals improve their technical and managerial skills. Seminar attendees will be more effective when they reenter the workforce. Construx hopes this program will help laid-off software workers reenter the workforce more quickly. 

Bellevue, WA, 12 February 2009 -- Construx Software today announced a complimentary program for training software workers who have been laid off during the recent economic downturn. Construx has designated 25% of the seats in its Software Development Best Practices training seminars free to personnel who have been laid off from professional software development jobs.

"During the dot com collapse the software industry was at the epicenter of the recession. Most of our clients were affected, and that meant we were affected," said Steve McConnell, Construx CEO and author of several best selling software development books. "We remember what it was like during the last downturn, and we are fortunate this time to be in a position to extend a helping hand to our friends whose companies are struggling."

One of Construx's corporate values is Sharing the Wealth. "Companies that are strong enough to lead us out of the recession should help in whatever ways we can," McConnell stated. "Professionals can take advantage of their downtime to improve their skills in ways that we hope will accelerate their job searches and continue to provide career-long benefits after they re-enter the workforce."

During boom periods many software professionals have difficulty finding time to sharpen their skills. "Our seminars focus on developing the skills needed to deliver world-class software. We want software people to be able to build their careers, whether they have a job at the moment or not," Mark Nygren, Construx's COO stated.

Construx 1-, 2-, and 3-day seminars cover subjects including Software Project Management, Software Estimation, Software Requirements, Software Design, Software Testing, and numerous other software development topics. Construx offers more than 50 public seminars each year at its training facility in Bellevue, Washington.

Construx's SPEAR (Software Professional Educational Assistance and Re-entry) program is slated to continue through June 2009. Software professionals who would like to participate in the SPEAR program should see SPEAR program details on the web at http://www.construx.com/spear. A full schedule of Construx's upcoming public seminars can be found on the web at http://www.construx.com/calendar.

About Construx Software

Construx Software is the market leader in software development best practices training and consulting. Construx was founded in 1996 by Steve McConnell, respected author and thought leader on software development best practices. McConnell's books Code Complete, Rapid Development, and other titles are some of the most accessible books on software development with a million copies in print in 20 languages. McConnell's passion for advancing the art and science of commercial software engineering is shared by Construx's seasoned consultants. Their depth of knowledge and expertise have helped hundreds of companies solve their software challenges by identifying and adopting practices proven to produce high quality software - faster, and with greater predictability. To learn more about Construx training and consulting services, visit Construx's Web site at http://www.construx.com. or call +1-866-296-6300. 

Contact:
Pam McIlroy, Marketing Manager
pam.mcilroy@construx.com
425.636.0116

###

The 2009 Executive Council for Software Excellence (ECSE) meeting topics have been announced. They are:

January	Successful Leadership in Software Development
February	Overcoming a Legacy of Poor Quality
March	Organizational Structures
April	Accelerating Organizational Change
May	Working Effectively with the Executive Team
June	Working with Distributed/Offshore Teams
July	The Business of Software Development
August	Game Night: Software Project Simulation Board Games (Bellevue) Summer break (dial-in)
September	Legacy Systems Issues: Support vs. development, managing technical debt, deciding when to rework and when to replace
October	Improving Productivity
November	Succeeding in Heterogenous Development Environments: Agile + Waterfall
December	Project Portfolio Management

The ECSE meets in-person in Bellevue, Washington the second Monday of each month from 5:00-7:00 pm, Pacific Time and via teleconference the Friday following the second Monday of each month from 11:00 am-12:00 noon, Eastern time (8:00-9:00 am Pacific time).

ECSE members are software executives and senior managers who have multi-project responsibility, typically with staffs of 100+. You can see more details at the ECSE Website (you'll need a free login to access this website). If you're interested in joining the group, please contact me.

We've recently posted a few new white papers on our website, along with some existing papers. These are free to members (and membership is free).

10 Keys to Successful Scrum Adoption
Scrum is a project management approach for Agile software development and is the most commonly adopted Agile approach in the industry today. Construx has worked with hundreds of organizations to implement Agile approaches including Scrum. We have helped numerous organizations to adopt the core principles of Scrum and to adapt it based on their unique situations and challenges. This paper discusses ten keys to successful Scrum adoption identified during our consulting and training work with clients. www.construx.com/whitepapers

Optimizing Agile for Your Organization
Many organizations are interested in becoming Agile but wonder where to start. They want to ensure that their Agile adoption will achieve the desired benefits, goals, and objectives. This white paper will outline the major organization, cultural, and project considerations that are critical to a successful Agile adoption. It provides a starting point that works for most projects and organizations. www.construx.com/whitepapers

Managing Technical Debt
"Technical Debt" refers to delayed technical work that is incurred when technical short cuts are taken,
usually in pursuit of calendar-driven software schedules. Just like financial debt, some technical
debts can serve valuable business purposes. Other technical debts are simply counterproductive.
The ability to take on debt safely, track their debt, manage their debt, and pay down their debt varies among different organizations. Explicit decision making before taking on debt and more explicit tracking of debt are advised. www.construx.com/whitepapers

Software Development's Classic Mistakes 2008
Construx's Chief Software Engineer/CEO, Steve McConnell, introduced the concept of software
development's classic mistakes in his book Rapid Development. He defined "classic mistakes" as
mistakes that have been made so often, by so many people, that the consequences of making
these mistakes should be predictable and the mistakes themselves should be avoidable.
This whitepaper is the result of a survey of Approximately 500 software practitioners to determine
the frequency and severity of common software development mistakes. www.construx.com/whitepapers

Say what you like about the new Bill Gates /Jerry Seinfeld ads, I have to approve Bill's choice of bedtime reading. He's reading from Section 18.2 of Code Complete 2. (It's about 1:10 into the video.)

http://www.youtube.com/watch?v=gBWPf1BWtkw

I thought I was the only person who read Code Complete 2 aloud to put their kids to sleep!