March 2008 - Posts

• Chief Programmer Team Update

  One spinoff from the 10x difference in programmer productivity was the Chief Programmer Team structure. The idea of the chief-programmer team was originally developed at IBM during the late 1960s (Baker 1972, Baker and Mills 1973). It was popularized by Fred Brooks in the Mythical Man-Month (Brooks 1975, 1995), in which Brooks referred to it as a surgical team. The two terms are interchangeable. I described the technique in my 1996 book Rapid Development, but I think we've learned some important lessons about the CPT structure since then. Original Chief Programmer Team Project The original chief programmer team project was conducted in the late 1960s. IBM commissioned to build an information retrieval system for the New York Times. The Chief Programmer on that project (the original Chief Programmer) was Harlan Mills, who created all the design and wrote all of the production code. He had eight other people arrayed around him in various support functions: A "backup programmer" serves as the chief programmer’s alter ego. The backup programmer supports the chief programmer as critic, research assistant, technical contact for outside groups, and backup-up chief. The "administrator" handles administrative matters such as money, people, space, and machines. The Chief has ultimate say about these matters, but the administrator frees the Chief from having to deal with them on a daily basis. The "toolsmith" is responsible for creating custom tools requested by the Chief . In today’s terminology, the toolsmith would be in charge of maintaining the build environment, creating scripts, etc.   The team is rounded out by a "language lawyer" who supports the Chief by answering esoteric questions about the programming language the Chief is using. Several of the support roles suggested in the original chief-programmer proposal are now regularly performed by nonprogrammers--by documentation specialists, test specialists, and program managers. Other tasks such as word processing and version control have been simplified so much by modern software tools that they no longer need to be performed by support personnel. And the internet has reduced the need for language lawyers--many questions can be answered via a quick search on the web. Attempts to Replicate IBM’s Chief Programmer Team Results: Is 10x Good Enough? On the original project, Harlan Mills personally wrote 83,000 lines of production code in one year. He wrote that code on a batch mode operating system. And on punch cards! Even when you divide the 83,000 lines of code by the nine people on the project, that’s 9,200 lines of code per staff year, which is still in the ballpark of acceptable productivity for similar kinds of projects 40 years later. With productivity like that under those circumstances you can see why the IBM project was heralded as one of the most successful projects of its time. In the years since that project many organizations have tried to implement Chief Programmer teams, and few have been able to repeat IBM’s initial stunning success. The achilles heel of the Chief Programmer Team model is that for it to make sense to organize staff the way they were organized on the IBM project, the Chief Programmer has to be more productive than everyone else on the team put together. On the original IBM project, Harlan Mills was a near-genius programmer who was an expert software methodologist, talented writer, exceptionally self-disciplined, and highly motivated. When he decided to roll up his sleeves and write code, he had few peers. Think "Kent Beck of His Day" and you’d be pretty close. He was one of the rare individuals truly capable of doing more work than the eight other people on his team put together. In a previous blog posting I discussed the fact that numerous studies have found 10-fold variations in productivity between the best and worst programmers with similar levels of experience. For the CPT model to work, the Chief Programmer doesn’t have to be 10x as productive as the worst programmer. He has to do the work of eight or nine people put together, which means he has to be 10x as productive as the average programmer, not 10x as productive as the worst. That’s a very tall order. If you assume the best programmer is 10x as productive as the worst, then the best will be only something like 2-3 as productive as the average programmer, and that isn’t good enough for the CPT model to pay off with a total project team of nine people. Another factor is that, while numerous studies have found 10x differences among individuals, researchers have not found 10-fold differences among programmers working within the same organizations. Some research has found that good programmers tend to cluster within certain companies, average programmers tend to cluster within other companies, and so on (Mills 1983). So even if there’s a 10x difference industrywide, the difference you’d typically see within a given company is more like 3-5x from best to worst, which means the difference from best to average is more like 1.5x or 2x within any given company. Bottom line: The Chief Programmer Team organization can make sense in the rare case in which you have a near genius on your staff--one that is dramatically more productive than the average programmer on your staff. But from I've seen there are far fewer near geniuses than there are near genius wannabees, and that limits the applicability of the technique. Resources  Construx's 10x Software Development Seminar. My company's answer to the question of "What does it take to move a team toward the 10x end of the scale?" My earlier earlier blog posting on 10x differences in productivity. My earlier blog posting on self-education. Construx's web resources for professional development. References Brooks, Frederick P., Jr. The Mythical Man-Month, Reading Massachusetts: Addison-Wesley, 1975. Brooks, Frederick P., Jr. The Mythical Man-Month, Anniversary Edition, Reading Massachusetts: Addison-Wesley, 1995. Baker, F. Terry. "Chief Programmer Team Management of Production Programming," IBM Systems Journal, vol. 11, no. 1, 1972, pp. 56-73. Baker, F. Terry and Harlan D. Mills. "Chief Programmer Teams." Datamation, Volume 19, Number 12 (December 1973), pp. 58-61. McConnell, Steve. Rapid Development. Microsoft Press, 1996. Mills, Harlan D. Software Productivity, Boston, Massachusetts: Little, Brown, 1983. Posted Mar 31 2008, 05:28 PM by Steve McConnell with 14 comment(s) Filed under: productivity, Management, Project Management, Team Organization, Chief Programmer Team

• Productivity Variations Among Software Developers and Teams: The Origin of "10x"

  Some blog readers have asked for more background on where the "10x" name of this blog cam from. The gist of the name is that researchers have found 10-fold differences in productivity and quality between different programmers with the same levels of experience and also between different teams working within the same industries. Individual Productivity Variation in Software Development The original study that found huge variations in individual programming productivity was conducted in the late 1960s by Sackman, Erikson, and Grant (1968). They studied professional programmers with an average of 7 years’ experience and found that the ratio of initial coding time between the best and worst programmers was about 20 to 1; the ratio of debugging times over 25 to 1; of program size 5 to 1; and of program execution speed about 10 to 1. They found no relationship between a programmer’s amount of experience and code quality or 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). There is also lots of anecdotal support for the large variation between programmers. During the time I was at Boeing in the mid 1980s, there was a project that had about 80 programmers working on it that was at risk of missing a critical deadline. The project was critical to Boeing, and so they moved most of the 80 people off that project and brought in one guy who finished all the coding and delivered the software on time. I didn't work on that project, and I didn't know the guy, so I'm not 100% sure the story is even true. But I heard the story from someone I trusted, and it seemed true at the time. This degree of variation isn't unique to software. A study by Norm Augustine found that in a variety of professions--writing, football, invention, police work, and other occupations--the top 20 percent of the people produced about 50 percent of the output, whether the output is touchdowns, patents, solved cases, or software (Augustine 1979). When you think about it, this just makes sense. We've all known people who are exceptional students, exceptional athletes, exceptional artists, exceptional parents--these differences are just part of the human experience; why would we expect software development to be any different? Extremes in Individual Variation on the Bad Side Augustine's study observed that, since some people make no tangible contribution whatsoever (quarterbacks who make no touchdowns, inventors who own no patents, detectives who don’t close cases, and so on), the data probably understates the actual variation in productivity. This appears to be true in software. In several of the published studies on software productivity, about 10% of the subjects in the experiments weren't able to complete the experimental assignment. In the studies, they writeups say, "Therefore those experimental subjects' results were excluded from our data set." But in real life if someone "doesn't complete the assignment" you can't just "exclude their results from the data set." You have to wait for them to finish, assign someone else to do their work, and so on. The interesting (and frightening) implication of this is that something like 10% of the people working in the software field might actually be contributing *negative& productivity to their projects. Again, this lines up well with real-world experience. I think many of us can think of specific people we've wworked with who fit that description. Team Productivity Variation in Software Development Software experts have long observed that team productivity varies about as much as individual productivity does--by an order of magnitude (Mills 1983). Part of the reason is that good programmers tend to cluster in some organizations, and bad programmers tend to cluster in other organizations, an observation that has been confirmed by a study of 166 professional programmers from 18 organizations (Demarco and Lister 1999). In one study of seven identical projects, the efforts expended varied by a factor of 3.4 to 1 and program sizes by a factor of 3 to 1 (Boehm, Gray, and Seewaldt 1984). In spite of the productivity range, the programmers in this study were not a diverse group. They were all professional programmers with several years of experience who were enrolled in a computer-science graduate program. It’s reasonable to assume that a study of a less homogeneous group would turn up even greater differences.   An earlier study of programming teams observed a 5-to-1 difference in program size and a 2.6-to-1 variation in the time required for a team to complete the same project (Weinberg and Schulman 1974). After reviewing data more than 20 years of data in constructing the Cocomo II estimation model, Barry Boehm and other researchers concluded that developing a program with a team in the 15th percentile of programmers ranked by ability typically requires about 3.5 times as many staff-months as developing a program with a team in the 90th percentile (Boehm et al 2000). The difference will be much greater if one team is more experienced than the other in the programming language or in the application area or in both. One specific data point is the difference in productivity between Lotus 123 version 3 and Microsoft Excel 3.0. Both were desktop spreadsheet applications completed in the 1989-1990 timeframe. Finding cases in which two companies publish data on such similar projects is rare, which makes this head-to-head comparison especially interesting. The results of these two projects were as follows: Excel took 50 staff years to produce 649,000 lines of code. Lotus 123 took 260 staff years to produce 400,000 lines of code. Excel's team produced about 13,000 lines of code per staff year. Lotus's team produced 1,500 lines of code per staff year. The difference in productivity between the two teams was more than a factor of 8, which supports the general claim of order-of-magnitude differences not just between different individuals but also between different project teams. What Have You Seen? Have you seen 10;1 differences in capabilities between different individuals? Between different teams? How much better was the best programmer you've worked with than the worst? Does 10:1 even cover the range? I look forward to hearing your thoughts. References Augustine, N. R. 1979. "Augustine’s Laws and Major System Development Programs." Defense Systems Management Review: 50-76. 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, 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. 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. Weinberg, Gerald M., and Edward L. Schulman. 1974. "Goals and Performance in Computer Programming." Human Factors 16, no. 1 (February): 70-77. Posted Mar 27 2008, 10:15 AM by Steve McConnell with 41 comment(s) Filed under: productivity, 10x, Individual Productivity, Team Productivity, Software Teams

• How to Scale Up Quickly

  The question of how to scale up quickly in a software startup company is a perennially tough issue. There are some good ways to get started -- starting with a core of really senior people is one time-honored approach. Starting with a core team of people who have worked together at another employer is another approach that often works. The question, though, is how do you scale up beyond that core, and how do you scale up quickly? I think it's an especially tough issue for people who are process oriented. If an organization is already pretty good sized, then having well defined and efficient processes can be supportive of scaling up quickly. Telecordia added something like 1000 people to its technical staff in the year it was first assessed at CMM Level 5. But that's a very large organization to start with. If you're in startup mode I think it's hard to add staff quickly without your organization's software practices reverting to whatever the industry mean in your geographic area is -- the new staff just has too strong a dilution effect on the existing staff for it to work any other way. Trying to startup quickly by outsourcing is a dead end as far as I'm concerned, especially to India where turnover is so high. Offshore captives can work, but minimum workable size seems to be about 100 people, and it probably takes 2-3 years of ramp up to get to financial break even. It's hard to find a time-to-market gain in this approach. So I think the only strategy that has much chance of working is being very, very selective about hiring, co-locating everyone at one facility, and making sure everyone has lots and lots of opportunity to interact both formally and informally, i.e., in addition to meetings you sponsor lots of morale events -- Friday afternoon beer busts, pizza & movie nights at work, trips to football games, dinner at the boss's house, etc. You won't be able to guarantee that the new people will work in ways that are consistent with how the existing people are working, but at least they'll work in ways that are intelligent and they'll be cooperating well. After things slow down a little you can go back in and try to establish more work conventions. You hope!   What do you think? In your experience, what are the best ways for a startup to scale up quickly? Posted Mar 18 2008, 08:22 AM by Steve McConnell with 7 comment(s) Filed under: Management, software startups

• Software Development Seminars in New York City

  I'll be in New York City next week teaching "Software Estimation in Depth." This is an enjoyable class to teach. It has great lab exercises, and it's fun to see the lightbulbs going off in people's heads as they "get" the key concepts in software estimation. You can read more about the class here: http://www.construx.com/Page.aspx?nid=17&id=32. My company's also teaching several other classes in New York City next week (the only time in 2008 we'll be doing open-enrollment seminars on the east coast). Other classes are: How to be Agile without Being Extreme 10x Software Engineering Requirements Boot Camp Software Project Management Boot Camp Design Boot Camp You can read more about all these classes at http://www.construx.com/Page.aspx?nid=387. Here are more detailed summaries of these classes. Software Estimation in Depth, March 24-25, 2008, Steve McConnell, Instructor  Details This course focuses on providing many useful rules of thumb and procedures for creating software estimates ("the art of estimation") and a brief introduction to mathematical approaches to creating software project estimates ("the science of estimation"). This course provides techniques for making sure estimation is treated as an analytical rather than a political process. It explains how to negotiate effectively with other project stakeholders (such as marketing, management and your clients) so that everyone wins. The course features extensive lab work to give you hands-on experience creating many different kinds of software estimates. This seminar will be taught by Steve McConnell, author of Code Complete, Rapid Development, and Software Estimation: Demystifying the Black Art. More > How to be Agile Without Being Extreme, March 24-25, 2008, Jerry Deville, Instructor  Details Agile software development promises low overhead, high flexibility, and satisfied customers, but how do you separate the hype from the reality? Leading organizations have benefited from Agile development practices for many years. Learn how to select and deploy today’s most powerful Agile practices. Apply the essentials of Scrum, Extreme Programming, Crystal, Lean, and other Agile methods. This intensive seminar presents modern practices combined with decades of time-tested, low-risk methods–all with a track record of proven results. This seminar is based on Construx’s experience working with companies that have successfully deployed Agile practices--and our experiences with companies whose agile projects have failed. Extensive case studies and hands-on exercises will show you how to select and apply the particular Agile development techniques that are best for your specific projects. More > 10x Software Engineering, March 26-28, 2008, Matt Peloquin, Instructor  Details Decades of research have found at least a ten-fold “10x” difference in productivity and quality between the best developers and the worst–and between the best teams and the worst. Discover the 5 Key Principles of 10x Engineering and avoid the productivity traps of “minus-x” engineering. Practice critical techniques that will turn your team into a high performing, 10x Team. More > Requirements Boot Camp, March 26-28, 2008, Earl Beede, Instructor  Details What is the most frequently reported cause of software project failure–regardless of project size or type of software? Requirements challenges. Discover how leading-edge companies use requirements engineering to support successful software projects. Learn the three purposes of requirements and how to distinguish between requirements fantasies and requirements reality. Practice practical techniques for exploring user needs, capturing requirements, controlling changes, and building highly satisfactory software. More > Software Project Management Boot Camp, March 26-28, 2008, Jerry Deville, Instructor  Details Leading any project can be a challenge. Leading a software project can be even more challenging if you're new to project management or new to software. This seminar will help you make the transition to solid software project leadership. Software Project Management Boot Camp teaches you the concepts and techniques necessary to manage projects successfully. This seminar closely follows the Project Management Institute's (PMI) Project Management Body of Knowledge (PM-BOK) and shows how to apply these best practices to a typical small to medium sized software project. More > Design Boot Camp, March 26-28, 2008, Steve Tockey, Instructor Details Different designers will create designs that differ by at least a factor of 10 in the code volume produced. How do you invent simple, straightforward designs and avoid complex, error-prone designs? Understand the fundamental design principles that lead to high-quality designs requiring low implementation effort. Learn both Agile and traditional approaches to create great designs quickly and economically. More > Posted Mar 18 2008, 08:15 AM by Steve McConnell with 1 comment(s) Filed under: seminars, New York City