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

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!

After Labor Day most of my focus goes into our annual Software Executive Summit. We are now in the final registration period -- with a $1000 public seminar voucher bonus for people who register by September 15.

I'm very excited about the speaker lineup this year. In addition to me, Martin Fowler, and Ken Schwaber, we have several very interesting industry speakers.

Mike Morrissey is VP Infrastructure at RIM, where he's responsible for the software that keeps all the Blackberries running. Blackberries have experienced meteoric growth, and Mike's going to talk about managing that.

Travis McElfresh is VP Technology at MSNBC.com, where he's managed to improve quality and productivity in a 24x7 news organization--and improve morale at the same time.

Matt Peloquin, Construx's CTO, is going to talk about our experiences doing technical evaluations with numerous companies over the past several years. His talk title is "Lessons from the Software Wild," which I think people will find appropriate once they hear what he has to say.

I hope you'll be able to attend, or that you'll let the executives in your organization know about this unique event. I've appended the official event email below.

Steve

Construx Software Executive Summit 2008 If you've been waiting to register for Construx's 2008 Executive Summit, this is the time! A few seats still remain. Register by September 15, 2008 and receive a $1000 voucher for Construx's public seminars, usable by you or anyone on your staff. A rare opportunity for Top Software Executives to explore Software Development challenges and solutions with a Highly Select Group of Executive Peers. The fifth annual Software Executive Summit provides a forum for Top Software Executives to compare, evaluate, and improve their Software Development practices and strategies at the Enterprise Level. Through stimulating keynote addresses and invigorating small group discussions, participants will develop new insights into their organizations and discover innovative solutions. For the past three years, more than 99% of Summit attendees said they would attend again within two years, and 100% said they would recommend the event to others. more > Attendees at past Summits have reported they find the direct discussions with executive peers to be the most valuable part of the Summit. Previous attendees have represented top companies including Microsoft, Intel, Intuit, Symantec, EMC, Adobe, Expedia, Disney, Pixar, GE, Honeywell, General Dynamics, Tektronix, Costco, Nordstrom, Eli Lilly, MetLife, Thomson Financial, ADP, Bank of America, and many others. Keynote Addresses more > Ken Schwaber, "Scaling Scrum." Schwaber is the co-creator of Scrum and was one of the early, visible proponents of lightweight, adaptive processes for software development. Martin Fowler, "Cultivating Great Architects and Designers." Fowler is Chief Scientist at Thoughtworks and author of Refactoring, UML Distilled, and other software development best sellers.  Mike Morrissey, "Managing in a Hyper-Growth Environment." Morrissey is the VP Infrastructure at RIM, the Blackberry company where he oversees the Blackberry infrastructure. Travis McElfresh, "Driving Employee Satisfaction, Morale, and Productivity at MSNBC.com." McElfresh is VP Technology at MSNBC.com. Matt Peloquin, "Technical Lessons From the Software Wild." Peloquin is CTO of Construx Software and oversees technical software evaluations for Construx clients. Steve McConnell, "Secrets of World Class Software Organizations." McConnell is author of Code Complete, Software Estimation, Rapid Development, and other software industry classics. Benefits of Attending more > Share and compare experiences with other software development executives Explore issues with industry experts including Steve McConnell, Martin Fowler, Ken Schwaber, and other Summit attendees Attend monthly Seattle-area ECSE meetings or dial-in meetings for two years Receive Construx's monthly Software Executive Report for two years "Speakers were world class. I kept saying to myself, 'Wow ... this is something I need to bring back and teach my team.'" -- Bob Cymbalski, Director, Engineering, Motricity     more comments > Discussion Topics more > Managing Global Development Navigating the Planning Cycle Improving Productivity Upgrading Your SDLC Successful Leadership in Software Development Guru Management: Special Issues in Managing Technical Personnel Lessons Learned in Agile Development Driving Improved Technical Practices Who Should Attend At past Summits 95% of participants have held titles of VP, CTO, Director, or higher. Most participants will oversee the activities of at least 50-100 software personnel. All participants should have multi-project responsibility for software development at the organization or enterprise level. "Construx continues to provide a unique, relevant opportunity to interact as a peer group. Absolutely best conference, hands down." -- David Spokane, Director, Software Engineering Office, EMC   more comments > Logistics more > The Summit will be held in downtown Seattle at the Grand Hyatt, October 27-29, 2008. Participation fee is $3495. Attendees will be assigned to discussion groups based on profiles submitted prior to the Summit. Reservations will be accepted on a first-come, first-served basis. Reserve your spot today! Registration Bonus! Register by September 15, 2008 and receive a $1000 voucher for Construx's public seminars, usable by you or anyone on your staff. Please forward this email to others who might be interested in this event. http://www.construx.com/summit/

Agile literature focuses on the benefits Agile provides to developers and development teams, with a secondary focus on the benefits Agile provides customers. Much of the Agile literature also asserts that Agile practices are more responsive to business needs.

Many businesses are embracing Agile and seeing significant benefits. Many other businesses are embracing Agile and regretting it. Why the different results?

A Cautionary Tale of Agile Development

At a previous Construx Software Executive Summit, one of the executives attending the event told the following story. In 2001 a major division of a well-known software company embraced Extreme Programming (XP) as the development approach they would use for a product development initiative involving a technical staff of about 200 people. The development team followed XP closely. They developed their software in short iterations. They sought close collaboration with customers and customer representatives. They kept quality high at all times. They had working software to demonstrate throughout the project. They were highly responsive to customer inputs and agile in changing direction based on those inputs.

Development went on for about two years. While the team was being highly responsive to customer input, that wasn't good enough. The cumulative total of its work was not converging to anything resembling a saleable product. Eventually the company concluded that the team was never going to produce a product, at which point most of the 200 people were laid off and the company reported a $50 million loss on the project.

What Went Wrong?

For this business some of the specific practices in XP were simply not well matched to the company's business needs. In particular, XP's emphasis at that time on defining requirements only one iteration at a time didn't provide for an overall product vision (aka roadmap, aka product definition) that would result in a compelling product. Many of the other XP practices probably worked fine. But the lack of comprehensive requirements combined with an emphasis on "embracing change" just enabled the company to move more quickly in the wrong direction. For this company, contrary to the Agile Manifesto, "responding to change" was not more important than "following a plan."

This is representative of other misfires we've seen in implementing Agile development. Technical leadership assumes Agile equals "good." But Agile doesn't equal "good"; it equals "more suitable for some circumstances" and "less suitable for other circumstances." Applying Agile in the wrong circumstances can cause major problems. A related issue is that "Agile" has become quite a large umbrella that covers dozens of specific practices. The more time goes by, the less useful the Agile buzzword becomes and the more meaningful it is to discuss specific practices instead.

Agility and Predictability

True agility--which means adopting a posture that allows you to respond rapidly to changing market conditions and customer demands--conflicts with predictability. Some businesses value agility, but many businesses value predictability more than they value the ability to change direction quickly. For those businesses, becoming more Agile is a second level consideration; the first level consideration is how to become more predictable. This was the problem that the company in the cautionary tale experienced. They got flexibility, but what they really needed was predictability.

Whether agility or predictability is more important depends both on what a business's customers are requesting and on how long-range the request is. Customers say, "I want this capability." In an ideal world, the business will be able to say, "OK, here it is right away." Being able to say "here it is right away" is what agility is all about.

Sometimes the work is too big to say "Here it is right away." In those cases, the business needs to say something like, "Sure, we can go that direction. This is a big piece of work and we can have that ready for you 22 weeks from now." That is where predictability starts to matter. When you say you'll deliver something in 22 weeks, you'd like to know that you really will deliver it in 22 weeks.

Agility and Multi-Site Development

Multi-site development has become increasingly common during the same period that Agile development has been on the rise, and these two trends are not always compatible. When a client tells me "we want our distributed teams to be more Agile," warning buzzers start going off in my head. Of the dozens of practices that can be called "Agile" some will help multi-location teams and some will undermine them.

Agile development commonly includes the major focuses of reducing paperwork, increasing the frequency and bandwidth of face-to-face communications, and emphasizing informal, incidental communication. Those focuses inherently run counter to spreading people out geographically, which reduces face-to-face time, reduces incidental communication, and in general reduces communication bandwidth. So some Agile practices are not a good match for multi-site teams.

Many other Agile practices can work fine in multi-site teams. For example the practice of breaking work up into smaller chunks and delivering it more often than has been done traditionally is an Agile practice that provides discipline that's valuable to multi-site teams. Other valuable practices include daily builds or continuous builds, daily stand-up meetings, automated regression testing, developer unit testing, time box development, small cross-functional teams, intensive short-term planning, involved coach/manager, and frequent retrospectives, just to name a few.

Introducing Agile Practices to a Business

When we introduce Agile to a new company the first thing we do is make sure that Agile software development is really what the business needs. Because "Agile" has become an all-encompassing term, we encourage our clients to be specific about what benefits they are looking for. If Agile turns out not to be what the business really needs, we work on building strengths in other areas.

With companies that do have a business justification for Agile, we look at specific practices:

• We identify which practices will best address the areas that are experiencing the most pain.
• We determine which specific Agile practices are going to provide the most bang for the buck for that company.
• We assess which Agile practices have the highest chances of being accepted within that company's existing technical culture and business culture.

The software industry has a long history of taking good, incremental improvements in development practices and then overextending them. Agile development is not the exception to the rule. In many cases, Agile development practices can help companies raise the bar on their software development efforts. By focusing on business needs first, and technical solutions second, companies can avoid Agile becoming the proverbial "solution in search of a problem."

I'm pleased to announce that we've added a new speaker to our already-stellar speaker lineup for this year's Software Executive Summit. Mike Morrissey, VP of Infrastructure at RIM (the BlackBerry company), will be giving a talk about Managing in a Hyper-Growth Environment (more details). Here's the talk description:

When your business is in a hyper-growth phase just keeping pace with change can be a full-time job. Research In Motion has seen the number of BlackBerry subscribers double every year, with 16 million subscribers at the end of first quarter FY09. To support this tremendous growth RIM’s Infrastructure Software Team has more than tripled over the last three years, presenting significant challenges related to team growth, cultural evolution, scalability, availability, feature growth, distribution and process maturity. In his presentation, Mike Morrissey will discuss these challenges and offer insight into staying ahead of the growth curve in a hyper-growth environment.

Mike joins our other speakers:

• Martin Fowler, "Cultivating Great Architects and Designers"
• Ken Schwaber, "Scaling Scrum"
• Travis McElfresh, VP Technology, MSNBC.com, "Driving Employee Satisfaction, Morale, and Productivity at MSNBC.com"
• Matt Peloquin, CTO, Construx Software, "Technical Lessons from the Software Wild"
• Steve McConnell, "Secrets of World Class Software Organizations"

For more details on this year's Software Executive Summit, please visit www.construx.com/summit/.

I am pleased to officially announce the details of the 2008 Software Executive Summit, to be held October 27-29, 2008 in Seattle, Washington.

The Summit provides a rare opportunity for top software executives to compare software development challenges and solutions in a small-group-discussion format. Their discussions are punctuated by thought-provoking keynote addresses by Martin Fowler, Ken Schwaber, Steve McConnell, and others.

For the past three years, 99.5% of Summit attendees said they would attend again within two years, and 100% said they would recommend the event to others.  See more comments... 

"Speakers were world class. I kept saying to myself, 'Wow ... this is something I need to bring back and teach my team.'" --Bob Cymbalski, Director, Engineering, Motricity    See more comments

Early Registration Incentive

Attendees who register by June 15 will receive 2007 Summit pricing of $3000 (goes up to $3495 after June 15) plus a credit of $2000 toward Construx's public seminars. Space is limited, so Register Now!

"Terrific conference. Great networking event. Being able to meet and learn from all the other software execs is a great opportunity. I've really enjoyed the conference. It's one of the few that I reserve a year in advance." -- Peter Scott, VP of Engineering, GeoMagic    See more comments

Who Should Attend

At past Summits, 95% of participants have held titles of VP, CTO, Director, or higher. All participants have multi-project responsibility for software development at the organization or enterprise level.

Keynotes

Here are more details on the keynote talks this year:

• Steve McConnell, author of Software Estimation and Code Complete, “Secrets of World Class Software Organizations”
• Martin Fowler, author of Refactoring and Patterns of Enterprise Application Architecture, “Cultivating Great Architects and Designers”
• Ken Schwaber, co-creator of Scrum, “Scaling Scrum”
• Travis McElfresh, VP Technology, “Driving Employee Satisfaction, Morale, and Productivity at MSNBC.com”
• Matt Peloquin, CTO, Construx Software, “Technical Lessons from the Software Wild”
• See more details

"Construx continues to provide a unique, relevant opportunity to interact as a peer group. Absolutely best conference, hands down." -- David Spokane, Director, Software Engineering Office, EMC    See more comments

Discussion Topics

Here is a preliminary list of topics for the Summit's small group discussions.

• Upgrading Your SDLC
• Successful Leadership in Software Development
• Managing Global Development
• Guru Management: Special Issues in Managing Technical Personnel
• Lessons Learned in Agile Development
• Navigating the Planning Cycle
• Driving Improved Technical Practices
• Improving Productivity
• See more details

"The Summit is the only conference of its kind. It is a unique blend of presentations and small group discussions with high caliber attendees. Many tools, ideas, and useful practices were discussed at a rapid pace. Every software exec should attend every year."  --John Colton, VP Engineering, Application Security, Inc.    See more comments

For more details on the Summit, see the Summit home page or register now!

One of my activities is moderating monthly discussion groups on software executive topics. The output of those meetings are captured in the Construx Software Executive Reports. Our newest report, "Managing Core Development," is now available. Here's an excerpt:

“Core” code always refers to code that is in some way more central than other product code. There are several variations on this theme: Most companies use “Core” to refer to architecture and functionality that multiple groups depend on. Reusable architectures, engines, toolsets, platforms, and frameworks are all examples of software that companies think of as core. “Core” can refer to code that has exceptionally high quality requirements. “Core” can refer to software components that provide competitive advantage. One company defines Core as anything that affects the user experience. In this company’s business, this seems to be a variation on the theme of “Core” referring to code that has exceptionally high quality requirements and that provides competitive advantage. In some cases, when data is of central importance to a company (e.g., product info for a web company), “Core” can also include data and data access. Parts of the software that require governance are also sometimes considered to be core. Core is also known variously as "Platform," "Application Architecture," "Infrastructure", and other terms. Why Set up a Core Group? The core team’s responsibility is to provide an easy path for other groups to use leading technology, i.e., make it easier for non-core developers to do a good job. Core groups are sometimes set up to tap into specialized skills of a group that are needed commonly across products. For example, a company that produces scientific software might have a core group that consists of science Ph.D.s who write core code to implement key company algorithms.When the core is managed well, it can accelerate development by providing tools that make other groups more efficient and effective in the short term, reduce the support burden in the long term, or both. Differences between Core Development and Product Development Companies report several common differences between product development and core development: Quality assurance tends to be more rigorous, because problems in the core can adversely affect multiple products. Management of the core tends to be more rigorous for the same reason—schedule problems in the core can adverse affect schedules for multiple projects. When the core changes, change impacts on all teams need to be considered. Support obligations for the core are nettlesome. How long will the core group support each version of the code that it produces? Supporting several versions across each of several products can quickly become an unmanageable support obligation. ...

For the rest of the report, see the listing of Construx Software Executive Reports or link to the specific report below. A free membership is required to view these reports. Here are some recent topics and links to their reports:

• Organizational Structures
• Upgrading Your SDLC
• Managing Global Development
• Navigating the Planning Cycle
• Managing Core Development

 

In 2007 my colleagues at Construx Software and I updated the list of classic mistakes from my 1996 book Rapid Development. Throughout 2007 we conducted a survey to determine the frequency and severity of these classic mistakes. In other words, we wanted to get a more quantitative sense of just how "classic" these classic mistakes are.

More than 500 people responded to the survey. The majority of them were involved with web and business systems. A significant minority were involved in shrink wrap/commercial systems, and about 10% were involved in embedded, system critical, systems, SaaS, or other kinds of software. About half the respondents were in lead/architect roles, about one-quarter in individual technical contributor roles, and the rest were in management or dual management/technical roles. The results are available in a white paper, "Software Development's Classic Mistakes 2008." You will need a login our main web site to download the white paper. (The log in is free.)

Excerpts from the Classic Mistakes Survey

Based on the survey responses, we computed the approximate frequency of the mistakes surveyed. Here is an excerpt from the white paper that shows the approximate frequency of occurrence of the most common classic mistakes:

We also examined how severe the mistakes are when they occur. This excerpt from the white paper describes which mistakes produce Catastrophic or Serious consequences the most often:

Finally, we made an assessment of which classic mistakes are most damaging overall. We multiplied the approximate average frequency of each mistake times its average severity to arrive at a Mistake Exposure Index (MEI). The MEI ranges from 0 to 10, with 10 being the worst. Here is an excerpt from the white paper that shows the classic mistakes with the worst MEIs:

Here is an excerpt that summarizes the average frequency and average severity of the mistakes with the highest MEIs:

Conclusions from the Classic Mistakes Survey

The raw survey results are interesting and so are some of the general trends.

One conclusion is that two of the mistakes added in 2008 (i.e., that weren't in my 1996 book Rapid Development) made the top 10:

• Confusing estimates with targets
• Excessive multi-tasking

This suggests that continued refinement of the classic mistakes list is worthwhile.

A second conclusion is that a few of the mistakes don't occur frequently enough or aren't severe enough when they do occur to really be considered "classic" mistakes:

A third conclusion is that many of the mistakes in the survey do indeed deserve to be called "classic" mistakes. I find it interesting that 8 of the top 10 mistakes in this year's report were listed in a book I published in 1996. If these mistakes were classic in 1996, they're even more classic 12 years later!

Final Thoughts

We'll be updating the classic mistakes survey in 2009, and we'd appreciate your input into the survey. You can take the survey in about 30 minutes. If you take the survey, we'll send you the results before they're made available to the general public.

Why do people keep making these mistakes? I'm interested to hear your thoughts.

Resources

• "Software Development's Classic Mistakes 2008" Construx white paper which includes the complete list of mistakes, descriptions of each mistake, and results from the survey for every classic mistake (login required).
• Classic Mistakes Survey
• My executive presentation on Classic Mistakes (login required)
• My nominations for Top 12 classic mistakes in 1996
• Excerpt from Rapid Development on classic mistakes

My last couple of posts on productivity variations among programmers and the Chief Programmer Team model gave rise to some discussion about hazards of measuring software productivity at the individual programmer level. Software engineering studies normally measure productivity in terms of time to complete a specific task, or sometimes in terms of lines of code per effort-hour, staff-month, or some other measure of effort. Regardless of how you choose to measure productivity, there will be issues.

Productivity in Lines of Code Per Staff Month

Software design is a non-determinisitic activity, and researchers have found 10x variations in the code volume that different designer/developers will generate in response to a particular problem specification. If productivity is measured as lines of code per staff month (or equivalent), that implicitly suggests that the programmer who writes 10 times the amount of code to solve a particular problem is more productive than the programmer who writes 1 times the amount of code. That clearly is not right. Some commenters on my previous blog entry asserted that great programmers always write less code. My observation is that there’s a correlation there, but I wouldn’t make that statement that strongly. I would say that great programmers always write clear code, and that often translates to less code. Sometimes the clearest, simplest, and most obvious design takes a little more code than a design that’s more "clever"--in those cases I think the great programmer will write more code to avoid an overly clever design solution. Regardless, the idea that productivity can be measured cleanly as "lines of code per staff month" is subject to problems either way.

The problem with measuring productivity in terms of lines of code per staff month is the old Dilbert joke about Wally coding himself a minivan. If you measure productivity in terms of volume of code generated, some people will optimize for that measure, i.e., they will find ways to write more lines of code, even if more lines of code aren’t needed. This isn’t really a problem with this specific way of measuring productivity. This really just speaks to the management chestnut that "what gets measured gets done," so you need to be careful what you measure.

Productivity in Function Points

Some of the problems of "lines of code per staff month" can be avoided by measuring program size in function points rather than lines of code. Function points are a "synthetic" measure of program size in which inputs, outputs, queries, and files are counted to determine program size. An inefficient design/coding style won’t generate more function points, so function points aren’t subject to the same issues as lines of code. They are however subject to more practical issues, namely that to get an accurate count of function points you need the services of a certified function point counter (which most organizations don’t have available), and the mapping between how function points are counted and individual work packages is rough enough that it becomes impractical to use them to ascertain the productivity of individual programmers.

What about Complexity?

Managers frequently mention this issue:  "I always give my best programmer the most difficult/most complex sections of code to work on. His productivity on any measured basis might very well be low compared to programmers who get easier assignments, but my other programmers would take twice as long." Yep. That’s a legitimate issue too.

Is There Any Way to Measure Individual Productivity?

Difficulties like these have led many people to conclude that measuring individual productivity is so fraught with problems that no one should even try. I think it is possible to measure individual productivity meaningfully, as long as  you keep several key factors in mind.

1. Don’t expect any single dimensional measure of productivity to give you a very good picture of individual productivity. Think about all the statistics that are collected in sports. We can’t even use a single measure to determine how good a hitter in baseball is. We consider batting average, home runs, runs batted in, on-base percentage, and other factors--and then we still argue about what the numbers mean. If we can’t measure the "good hitter" using a simple measure, why would we expect we could measure something as complex as individual productivity using a simple measure? What we need to do instead is use a combination of measures, which collectively will give us insights into individual productivities. (Measures could include on-time task completion percentage, manager evaluation on a scale of 1-10, peer evaluation on a scale of 1-10, lines of code per staff month, defects reported per line of code, defects, fixed per line of code, bad fix injection rate, etc.)

2. Don’t expect any measures--whether single measures of a combination of measures--to support fine-grain discriminations in productivity among individuals. A good guideline is that measures of individual productivity give you questions to ask but they don’t give you the answers. Using measures of performance for, say, individual performance reviews is both bad management and bad statistics.

3. Remember that trends are usually more important than single-point measures. Measures of individual productivity tend to be far less useful in comparing one individual to another than they are in seeing how one individual is progressing over time.

4. Ask why you need to measure individual productivity at all. In a research setting, researchers need to measure productivity to assess the relative effectiveness of different techniques, and their use of these measures is subject to far fewer problems than measuring individual productivity on real projects is. In a real project environment, what do you want to use the measure(s) for? Performance reviews? Not a good idea for the reasons mentioned above. Task assignments? Most managers I talk with say they *know* who their star contributors are without measuring, and I believe them. Estimation? No, the variations caused by different design approaches, different task difficulty, and related factors make that an ineffective way to build up project estimates.

On real projects it’s hard to find a use for individual productivity measures that is both useful and statistically valid. In my experience, aside from research settings the attempt to measure individual performance arises most often from a desire to do something with the measurements that isn’t statistically valid. So while I see the value of measuring individual performance in research settings, I think it’s difficult to find cases in which the effort is justified on real projects.

(Measuring team productivity and organizational productivity is a different matter -- I'll blog about that soon).

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.

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.

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.

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 >

[This is an expansion of one of my comments on an earlier Technical Debt post]

When you get to a point where you are debating taking on technical debt, people normally consider two possible paths, one of which is the "good but expensive" path and the other of which is the "quick and dirty" path. When teams reach that decision point, they often estimate the good path and the quick path. Those estimates will help inform which path the team should choose at that moment. But there are three more issues that should considered.

The first additional issue to be considered is how much it will cost to backfill the good path after you've already gone down the quick path? Backfilling the good path will typically be more expensive than just following the good path in the first place because the work will include ripping out the quick code, making sure you didn't introduce any errors while doing that, then adding the good code and going through the normal test & QA processes. The "ripping out" part makes it cost more to implement the good path later than it would have cost to implement it in the first place. And of course you've already incurred the cost of the quick path, so the real cost is the sum of the quick path + the good path + the cost to rip out the quick path.

If the code is really well designed the "ripping out" cost can be minimal, but I think that's the exception.

The second additional issue that should be considered is the interest payment on the technical debt. I.e., if you choose the quick path now, how much does that slow down other work until you're able to retrofit the good path? The size of the "interest payment" depends very much on the specific case. Sometimes the "interest" is really just the cost of ripping out the quick code and of implementing the good code, which isn't really interest, per se. It's more like a late payment fee. Other times the quick and dirty approach does create ongoing interest payments by making related work in that same area take longer.

This leads us to the third issue that should be considered: Is there a path that is quicker than the good path and that won't affect the rest of the system? In other words, is there a quick path that can be isolated from the rest of the system in such a way that it doesn't create any ongoing interest payment/make other work more difficult? In my experience teams often turn the technical debt decision into a simplistic "two option" decision -- good path vs. quick and dirty path. Pushing through to a third option is important because often the best path is the one that is fairly quick, albeit not as quick as the pure quick and dirty path, and whose adverse affects are better contained than those of the pure quick and dirty path.

With those three options, the decision table for deciding which kind of technical debt to take on could look something like this (assuming a labor cost of $600/staff day):

Option 1: Good Path

Immediate cost of Good Solution: 10 staff days
Deferred cost to retrofit Good Solution: 0 staff days

Option 1 cost now: $6,000
Option 1 cost later: $0
Option 1 lifetime cost: $6,000

Option 2: Pure Quick & Dirty Path

Immediate cost of Quick & Dirty solution with possible interest payment: 2 staff days
Deferred cost to retrofit Good Solution: 12 staff days
Estimated cost of "interest payments": 0.5 staff days/month

Option 2 cost now: $1,200
Option 2 ongoing cost (interest): $600-$1,800 (assuming good solution is implemented within 6 months)
Option 2 cost later: $7,200
Option 2 lifetime cost: $9,000-$10,200

Option 3: Quick but not Dirty path

Immediate cost of Quick & Dirty solution with no interest payment: 3 staff days
Deferred cost to retrofit Good Solution: 12 staff days

Option 3 cost now: $1,800
Option 3 ongoing cost (interest): $0
Option 3 cost later: $7,200
Option 3 lifetime cost: $9,000

In this example, either Option 2 or Option 3 is an attractive short-term alternative to Option 1. That is, either $1200 or $1800 is a fraction of the cost/effort of $6000. But if you select Option 2 you saddle yourself with an obligation to revise the code later--either you reimplement the good solution, which costs more, or you keep paying interest, which costs more. When you select Option 3 you introduce the possibility of choosing never to pay off the technical debt, because there isn't any ongoing penalty, and so there isn't any urgency to pay off the debt.

Bottom line: When facing the prospect of taking on technical debt, be sure to generate more than two design options. Don't oversimplify technical debt decision making to just the two extremes.

The term "technical debt" was coined by Ward Cunningham to describe the obligation that a software organization incurs when it chooses a design or construction approach that's expedient in the short term but that increases complexity and is more costly in the long term.

 

Ward didn't develop the metaphor in very much depth. The few other people who have discussed technical debt seem to use the metaphor mainly to communicate the concept to technical staff. I agree that it's a useful metaphor for communicating with technical staff, but I'm more interested in the metaphor's incredibly rich ability to explain a critical technical concept to non-technical project stakeholders.

 

What is Technical Debt? Two Basic Kinds

The first kind of technical debt is the kind that is incurred unintentionally. For example, a design approach just turns out to be error-prone or a junior programmer just writes bad code. This technical debt is the non-strategic result of doing a poor job. In some cases, this kind of debt can be incurred unknowingly, for example, your company might acquire a company that has accumulated significant technical debt that you don't identify until after the acquisition. Sometimes, ironically, this debt can be created when a team stumbles in its efforts to rewrite a debt-laden platform and inadvertently creates more debt. We'll call this general category of debt Type I.

 

The second kind of technical debt is the kind that is incurred intentionally. This commonly occurs when an organization makes a conscious decision to optimize for the present rather than for the future. "If we don't get this release done on time, there won't be a next release" is a common refrain—and often a compelling one. This leads to decisions like, "We don't have time to reconcile these two databases, so we'll write some glue code that keeps them synchronized for now and reconcile them after we ship." Or "We have some code written by a contractor that doesn't follow our coding standards; we'll clean that up later." Or "We didn't have time to write all the unit tests for the code we wrote the last 2 months of the project. We'll right those tests after the release." (We'll call this Type II.)

 

The rest of my comments focus on the kind of technical debt that's incurred for strategic reasons (Type II).

 

Short-Term vs. Long-Term Debt

With real debt, a company will maintain both short-term and long-term debt. You use short-term debt to cover things like gaps between your receivables (payments from customers) and expenses (payroll). You take on short term debt when you have the money, you just don't have it now. Short-term debt is expected to be paid off frequently. The technical equivalent seems straightforward. Short-term debt is the debt that's taken on tactically and reactively, usually as a late-stage measure to get a specific release out the door. (We'll call this Type II.A.)

 

Long term debt is the debt a company takes on strategically and proactively--investing in new capital equipment, like a new factory, or a new corporate campus. Again, the technical equivalent seems straightforward: "We don't think we're going to need to support a second platform for at least five years, so this release can be built on the assumption that we're supporting only one platform." (We'll call this Type II.B.)

 

The implication is that short-term debt should be paid off quickly, perhaps as the first part of the next release cycle, whereas long-term debt can be carried for a few years or longer.

 

Incurring Technical Debt

When technical debt is incurred for strategic reasons, the fundamental reason is always that the cost of development work today is seen as more expensive than the cost will be in the future. This can be true for any of several reasons.

 

Time to Market. When time to market is critical, incurring an extra $1 in development might equate to a loss of $10 in revenue. Even if the development cost for the same work rises to $5 later, incurring the $1 debt now is a good business decision.

 

Preservation of Startup Capital. In a startup environment you have a fixed amount of seed money, and every dollar counts. If you can delay an expense for a year or two you can pay for that expense out of a greater amount of money later rather than out of precious startup funds now.

 

Delaying Development Expense. When a system is retired, all of the system's technical debt is retired with it. Once a system has been taken out of production, there's no difference between a "clean and correct" solution and a "quick and dirty" solution. Unlike financial debt, when a system is retired all its technical debt is retired with it. Consequently near the end of a system's service life it becomes increasingly difficult to cost-justify investing in anything other than what's most expedient.

 

Be Sure You Are Incurring The Right Kind of Technical Debt

Some debt is taken on in large chunks: "We don't have time to implement this the right way; just hack it in and we'll fix it after we ship." Conceptually this is like buying a car—it's a large debt that can be tracked and managed. (We'll call this Type II.A.1.)

 

Other debt accumulates from taking hundreds or thousands of small shortcuts--generic variable names, sparse comments, creating one class in a case where you should create two, not following coding conventions, and so on. This kind of debt is like credit card debt. It's easy to incur unintentionally, it adds up faster than you think, and it's harder to track and manage after it has been incurred. (We'll call this Type II.A.2.)

 

Both of these kinds of debt are commonly incurred in response to the directive to "Get it out the door as quickly as possible." However, the second kind (II.A.2) doesn't pay off even in the short term of an initial development cycle and should be avoided.

 

Debt Service

One of the important implications of technical debt is that it must be serviced, i.e., once you incur a debt there will be interest charges.

 

If the debt grows large enough, eventually the company will spend more on servicing its debt than it invests in increasing the value of its other assets. A common example is a legacy code base in which so much work goes into keeping a production system running (i.e., "servicing the debt") that there is little time left over to add new capabilities to the system. With financial debt, analysts talk about the "debt ratio," which is equal to total debt divided by total assets. Higher debt ratios are seen as more risky, which seems true for technical debt, too.

 

Attitudes Toward Technical Debt

Like financial debt, different companies have different philosophies about the usefulness of debt. Some companies want to avoid taking on any debt at all; others see debt as a useful tool and just want to know how to use debt wisely.

 

I've found that business staff generally seems to have a higher tolerance for technical debt than technical staff does. Business executives tend to want to understand the tradeoffs involved, whereas some technical staff seem to believe that the only correct amount of technical debt is zero.

 

The reason most often cited by technical staff for avoiding debt altogether is the challenge of communicating the existence of technical debt to business staff and the challenge of helping business staff remember the implications of the technical debt that has previously been incurred. Everyone agrees that it's a good idea to incur debt late in a release cycle, but business staff can sometimes resist accounting for the time needed to pay off the debt on the next release cycle. The main issue seems to be that, unlike financial debt, technical debt is much less visible, and so people have an easier time ignoring it.

 

How do You Make an Organization's Debt Load More Visible?

One organization we've worked with maintains a debt list within its defect tracking system. Each time a debt is incurred, the tasks needed to pay off that debt are entered into the system along with an estimated effort and schedule. The debt backlog is then tracked, and any unresolved debt more than 90 days old is treated as critical.

 

Another organization maintains its debt list as part of its Scrum product backlog, with similar estimates of effort required to pay off each debt.

 

Either of these approaches can be used to increase visibility into the debt load and into the debt service work that needs to occur within or across release cycles. Each also provides a useful safeguard against accumulating the "credit card debt" of a mountain of tiny shortcuts mentioned earlier. You can simply tell the team, "If the shortcut you are considering taking is too minor to add to the debt-service defect list/product backlog, then it's too minor to make a difference; don't take that shortcut. We only want to take shortcuts that we can track and repair later."

 

Ability to Take on Debt Safely Varies

Different teams will have different technical debt credit ratings. The credit rating reflects a team's ability to pay off technical debt after it has been incurred.

 

A key factor in ability to pay off technical debt is the level of debt a team takes on unintentionally, i.e., how much of its debt is Type I? The less debt a team creates for itself through unintentional low-quality work, the more debt a team can safely absorb for strategic reasons. This is true regardless of whether we're talking about taking on Type I vs. Type II debt or whether we're talking about taking on Type II.A.1 vs. Type II.A.2 debt.

 

One company tracks debt vs. team velocity. Once a team's velocity begins to drop as a result of servicing its technical debt, the team focuses on reducing its debt until its velocity recovers. Another approach is to track rework, and use that as a measure of how much debt a team is accumulating.

 

Retiring Debt

"Working off debt" can be motivational and good for team morale. A good approach when short-term debt has been incurred is to take the first development iteration after a release and devote that to paying off short-term technical debt.

 

The ability to pay off debt depends at least in part on the kind of software the team is working on. If a team incurs short-term debt on a web application, a new release can easily be rolled up after the team backfills its debt-reduction work. If a team incurs short-term debt in avionics firmware— the pay off of which which requires replacing a box on an airplane— that team should have a higher bar for taking on any short-term debt. This is like a minimum payment--if your minimum payment is 3% of your balance, that's no problem. If the minimum payment is $1000 regardless of your balance, you'd think hard about taking on any debt at all.

 

Communicating about Technical Debt

The technical debt vocabulary provides a way to communicate with non-technical staff in an area that has traditionally suffered from a lack of transparency. Shifting the dialog from a technical vocabulary to a financial vocabulary provides a clearer, more understandable framework for these discussions. Although the technical debt terminology is not currently in widespread use, I've found that it resonates immediately with every executive I've presented it to as well as other non-technical stakeholders. It also makes sense to technical staff who are often all-too-aware of the debt load their organization is carrying.

 

Here are some suggestions for communicating about debt with non-technical stakeholders:

 

Use an organization's maintenance budget as a rough proxy for it's technical debt service load. However you will need to differentiate between maintenance that keeps a production system running vs. maintenance that extends the capabilities of a production system. Only the first category counts as technical debt.

 

Discuss debt in terms of money rather than in terms of features. For example, "40% of our current R&D budget is going into supporting previous releases" or "We're currently spending $2.3 million per year servicing our technical debt."

 

Be sure you're taking on the right kind of debt. Not all debts are equal. Some debts are the result of good business decisions; others are the result of sloppy technical practices or bad communication about what debt the business intends to take on. The only kinds that are really healthy are Types II.A.1 and II.B.

 

Treat the discussion about debt as an ongoing dialog rather than a single discussion. You might need several discussions before the nuances of the metaphor fully sink in.

 

Technical Debt Taxonomy

Here's a summary of the kinds of technical debt:

 

Non Debt

   Feature backlog, deferred features, cut features, etc. Not all incomplete work is debt. These aren't debt, because they don't require interest payments.

 

Debt

   I. Debt incurred unintentionally due to low quality work

   II. Debt incurred intentionally

      II.A. Short-term debt, usually incurred reactively, for tactical reasons

         II.A.1. Individually identifiable shortcuts (like a car loan)

         II.A.2. Numerous tiny shortcuts (like credit card debt)

      II.B. Long-term debt, usually incurred proactively, for strategic reasons

 

Summary

What do you think? Do you like the technical debt metaphor? Do you think it's a useful way to communicate the implications of technical/business decision making to non-technical project stakeholders? What's your experience? I look forward to your thoughts.

 

Resources

• Ward Cunningham's OOPSLA '92 Experience Report that first mentions technical debt.

• Martin Fowler's brief bliki entry about technical debt.

• c2 wiki discussions of Complexity As Debt and Technical Debt.