The speed at which a developer writes code has nothing to do with how fast the developer types. It’s all about how well he understands the code that he is asked to modify. When a developer is assigned a task, he needs to understand what the existing code is doing, how to change what it’s doing, and be able to foresee the impact of his changes. This requires code knowledge. Thus, expanding each developer’s code knowledge will broaden the range of tasks that you can assign each developer, as well as reduce the time required to complete each task. How do you achieve this?
One way is through peer code review. When one developer reviews another’s code, he learns about code complexities and connections. This ends up expanding the amount of code that each developer can work on, and the speed at which tasks are completed. In addition to expanding the knowledge of the reviewers, this process also provides additional insight to the reviewee, who receives valuable team member feedback on how the code he wrote relates to the code base as a whole. To learn more about how to optimize your peer code review process, see Peer Code Review Best Practices.
Another way to increase code knowledge is through regression testing. If a developer is not familiar with the code and has to change it, his greatest concern is probably breaking something that’s already working. Regression test suites instantly alert developers to any unexpected impacts—for instance, if a modification changes or breaks some existing functionality in another part of the application. In addition to teaching developers them about correlations between the modified code and the other parts of the code base, this also increases productivity by giving developers the courage to improve and extend code without being stunted by fear.
Expanding each developer’s code knowledge also promotes productivity by preventing mistakes that lead to debugging and rework, which are discussed in the next two equations. The less familiar developers are with the code, the more prone they are to make mistakes that will slow productivity long after the implemented piece of code is first checked in.
Monday, June 7, 2010
Wednesday, May 19, 2010
Equation 1: Have a Clear, Actionable Plan of Attack
The more time a developer spends wondering which requirement or task to tackle next and how to address it, the less time he is actually performing productive, rewarding work—creative tasks that help the organization achieve its goals.
To keep developers focused on performing productive work, define tasks properly, have a system for distributing tasks, and assign tasks properly.
Define tasks properly
In software development, tasks are often quite nebulous: they are vaguely defined, and thus it is difficult for developers to determine where to start tackling them and how to proceed. To overcome this challenge, it’s essential to have someone (e.g., an architect or manager) with a good conceptual grasp of the application being developed. This person can take high-level requirements and translate them into more granular tasks that a developer can quickly understand and then successfully implement.
When developers are assigned to work on smaller tasks (for example, work tasks that are scoped to be no greater than one day) as opposed to being assigned to participate in one large, nebulous task, experience has shown that they become much more productive. Since the developers understand exactly where to start and what to do, they become much more efficient: their tasks are attainable and progress is immediately recognized.
Have a system for distributing tasks
Ideally, developers should always have a prioritized list of tasks in front of them, in their natural development environment. This reduces any guesswork as to what is expected and how to proceed.
Assign tasks properly
If a task is assigned to a developer who is unfamiliar with the related piece of code, the implementation time (and the risk of debugging and rework) will be significantly greater than if that same task were assigned to a developer who was intimately familiar with the related code.
To learn more about how to optimize task management with Parasoft Concerto, see Project Center – Manage Tasks.
To keep developers focused on performing productive work, define tasks properly, have a system for distributing tasks, and assign tasks properly.
Define tasks properly
In software development, tasks are often quite nebulous: they are vaguely defined, and thus it is difficult for developers to determine where to start tackling them and how to proceed. To overcome this challenge, it’s essential to have someone (e.g., an architect or manager) with a good conceptual grasp of the application being developed. This person can take high-level requirements and translate them into more granular tasks that a developer can quickly understand and then successfully implement.
When developers are assigned to work on smaller tasks (for example, work tasks that are scoped to be no greater than one day) as opposed to being assigned to participate in one large, nebulous task, experience has shown that they become much more productive. Since the developers understand exactly where to start and what to do, they become much more efficient: their tasks are attainable and progress is immediately recognized.
Have a system for distributing tasks
Ideally, developers should always have a prioritized list of tasks in front of them, in their natural development environment. This reduces any guesswork as to what is expected and how to proceed.
Assign tasks properly
If a task is assigned to a developer who is unfamiliar with the related piece of code, the implementation time (and the risk of debugging and rework) will be significantly greater than if that same task were assigned to a developer who was intimately familiar with the related code.
To learn more about how to optimize task management with Parasoft Concerto, see Project Center – Manage Tasks.
Wednesday, May 5, 2010
Equations for Efficiency
Over 21 years of developing software ourselves and assisting other organizations to deliver better software faster, Parasoft has determined that improving software development productivity really boils down to the following equations:
In fact, these ideas are not so novel. Other industries have struggled with the same types of productivity issues that the software development industry is facing today, and enjoyed tremendous success by adopting the same core approaches. By applying them in our own industry, we can bring software development productivity to more rewarding and competitive levels.
In our experience, we have found that applying the following equations leads to astonishing increases in productivity. For instance, applying them internally at Parasoft enables us to have 120 developers working on 48 million lines of code. This works out to about 400,000 LOC per developer, which is significantly more than the “10,000-20,000 LOC per developer” industry average referenced in my previous post.
- Having a clear, actionable plan of attack = Productivity
- Increasing code knowledge = Productivity
- Reducing rework = Productivity
- Reducing debugging = Productivity
In fact, these ideas are not so novel. Other industries have struggled with the same types of productivity issues that the software development industry is facing today, and enjoyed tremendous success by adopting the same core approaches. By applying them in our own industry, we can bring software development productivity to more rewarding and competitive levels.
In our experience, we have found that applying the following equations leads to astonishing increases in productivity. For instance, applying them internally at Parasoft enables us to have 120 developers working on 48 million lines of code. This works out to about 400,000 LOC per developer, which is significantly more than the “10,000-20,000 LOC per developer” industry average referenced in my previous post.
Monday, March 29, 2010
Adding Developers Is Not the Solution
It’s important to note that adding developers to the project— which is probably the most common attempt to move a project along faster—actually decreases productivity according to this equation.
This might seem illogical at first, but when you think about what happens when new developers join a team, it makes sense.
Adding new developers initially hinders the team from making the usual progress on their tasks. First off, existing team members need to spend time training and communicating with the new team members. More critically, new developers have a limited understanding of your team’s code base. As a result, they cannot efficiently revise the existing code (which, as I mentioned above, accounts for the bulk of software development), and this limits the team’s progress. Their lack of familiarity with the code base also increases the risk of introducing defects and other issues that will later require rework. This too hinders productivity. (In the next section, we’ll look more closely at why all these things impact productivity).
Rather than expanding the team size, the key to completing work faster is making the existing development process more efficient: in other words, increasing the average LOC per head. This is the same lesson that was learned time and time again in other industries. As production processes are optimized and take advantage of the latest technologies, fewer people are needed on the “production line” because those people are able to accomplish more than they did previously—in less time.
The next entries will introduce four ways to optimize the development “production line” to significantly increase the productivity of each developer.
This might seem illogical at first, but when you think about what happens when new developers join a team, it makes sense.
Adding new developers initially hinders the team from making the usual progress on their tasks. First off, existing team members need to spend time training and communicating with the new team members. More critically, new developers have a limited understanding of your team’s code base. As a result, they cannot efficiently revise the existing code (which, as I mentioned above, accounts for the bulk of software development), and this limits the team’s progress. Their lack of familiarity with the code base also increases the risk of introducing defects and other issues that will later require rework. This too hinders productivity. (In the next section, we’ll look more closely at why all these things impact productivity).
Rather than expanding the team size, the key to completing work faster is making the existing development process more efficient: in other words, increasing the average LOC per head. This is the same lesson that was learned time and time again in other industries. As production processes are optimized and take advantage of the latest technologies, fewer people are needed on the “production line” because those people are able to accomplish more than they did previously—in less time.
The next entries will introduce four ways to optimize the development “production line” to significantly increase the productivity of each developer.
Wednesday, March 3, 2010
How to Calculate Software Development Productivity
There have been many attempts to define metrics that effectively measure software development productivity. Most of the ones that I have seen are amazingly complicated and very difficult to apply.
A simpler productivity metric is the total number of lines of code in the organization divided by the number of people who are working on that code (including QA as well as development). For short, I will call this metric the average LOC per head. Essentially, it represents the developer horizon: how much code each developer really understands.
This measurement is an excellent representation of the development organization’s true productivity. If the number is high, it means that you have a relatively low number of people working on code. In other words, you are accomplishing a lot with minimal resources.
Approximately 10-20 thousand lines of code per developer is the norm for most of today’s development organizations. This is based on the current industry averages that report a typical program has about a million lines of code, and there are usually about 50 to 80 developers working on that code base.
LOC per head – Does it really vary over time?
After I introduce this metric, I’m often asked, “Does this refer to the number of lines of code per head per month? Per week? Or something else?”
I respond that the time period is irrelevant. Why? Because as a software product evolves, its number of lines of code remains relatively constant.
Among non-developers, there is a misconception that the code base continuously grows as development occurs. However, if you talk to developers, you’ll find that most development work—even adding new functionality—really boils down to refactoring existing code.
With the exception of the prototyping phase at the beginning of a completely new development project (a phase that usually lasts a matter of weeks), development primarily involves reworking existing code. Thus, each developer’s understanding of the code base is critical for development productivity. As I’ll discuss in more detail later, the more code each team member truly understands and can efficiently modify, the more productive the team becomes.
A simpler productivity metric is the total number of lines of code in the organization divided by the number of people who are working on that code (including QA as well as development). For short, I will call this metric the average LOC per head. Essentially, it represents the developer horizon: how much code each developer really understands.
This measurement is an excellent representation of the development organization’s true productivity. If the number is high, it means that you have a relatively low number of people working on code. In other words, you are accomplishing a lot with minimal resources.
Approximately 10-20 thousand lines of code per developer is the norm for most of today’s development organizations. This is based on the current industry averages that report a typical program has about a million lines of code, and there are usually about 50 to 80 developers working on that code base.
LOC per head – Does it really vary over time?
After I introduce this metric, I’m often asked, “Does this refer to the number of lines of code per head per month? Per week? Or something else?”
I respond that the time period is irrelevant. Why? Because as a software product evolves, its number of lines of code remains relatively constant.
Among non-developers, there is a misconception that the code base continuously grows as development occurs. However, if you talk to developers, you’ll find that most development work—even adding new functionality—really boils down to refactoring existing code.
With the exception of the prototyping phase at the beginning of a completely new development project (a phase that usually lasts a matter of weeks), development primarily involves reworking existing code. Thus, each developer’s understanding of the code base is critical for development productivity. As I’ll discuss in more detail later, the more code each team member truly understands and can efficiently modify, the more productive the team becomes.
Thursday, February 11, 2010
Why Productivity Matters
In today’s economy, software development is a great expense for most organizations, so lagging software development productivity can have a significant impact on the organization’s ability to compete and survive. Currently, most software development organizations are not optimized. The C-level still considers software development a cost center with poorly-understood processes and deliverables. There is an increasing demand for software—especially for embedded systems. However, without improved efficiency, it will be difficult to take advantage of these opportunities in a cost-effective manner.
This requires more than tools; it calls for a process that ensures quality software can be produced consistently and efficiently. Like the various automobile manufacturers, different development organizations today typically have access to roughly the same production tools and technologies. The organizations that have a process for leveraging them most successfully are the ones with the highest productivity and the lowest production costs—and the best poised to compete.
My next few posts will present one simple equation for assessing your team’s current efficiency level, then four equations you can apply to improve it:
This requires more than tools; it calls for a process that ensures quality software can be produced consistently and efficiently. Like the various automobile manufacturers, different development organizations today typically have access to roughly the same production tools and technologies. The organizations that have a process for leveraging them most successfully are the ones with the highest productivity and the lowest production costs—and the best poised to compete.
My next few posts will present one simple equation for assessing your team’s current efficiency level, then four equations you can apply to improve it:
- Having a clear, actionable plan of attack = Productivity
- Increasing code knowledge = Productivity
- Reducing rework = Productivity
- Reducing debugging = Productivity
Thursday, January 14, 2010
Software Development Management
Parasoft Concerto for Application Life Cycle Management (ALM)
Parasoft has been developing software for more than 20 years. During this time, we have come to understand that there is no silver bullet for the creation and maintenance of software. Although we are great proponents of automation and analysis, we are the first to admit that there is no single tool, technology, or technique that can, on its own, improve productivity, guarantee quality, and ensure that project deadlines are met.
Over the years, Parasoft explored many different tools and technologies that held promise for improving code, application, or project quality. Parasoft’s research and development not only explored these options from an internal productivity perspective, but also from the business value perspective—given our history of selling development organizations tools that assist in preventing software defects.
Our bottom line was that if we could not find a way for our own team to adopt a specific technique or technology as a process, then we deemed it superfluous and moved on. More importantly, we discovered that the “good” practices transcend methodology. It does not matter if you declare your process to be waterfall, agile, or iterative. The common denominator is that developers must write code and technology must complement the individual. It must be non-intrusive, automated, and follow the human workflow.
Personally, given our industry’s appetite for technology, I’m a bit amazed that software development organizations have not adopted tighter, more disciplined processes leveraging the available automation. However, we have reached an inflection point in the business of developing software: a point where there is a distinct need for greater productivity and a sense of urgency for better software quality.
In 2009, Parasoft released Parasoft Concerto: a complete ALM platform that ensures quality software can be produced consistently and efficiently. I feel that Parasoft Concerto is an optimal combination of tools, processes, and infrastructure that can increase development productivity by orders of magnitude. We refer to this category of development infrastructure as Software Development Management (SDM).
If you'd like to learn about how the Parasoft Concerto ALM platform assists to increase productivity throughout the SDLC, I encourage you to read more at Software Development Management.
Subscribe to:
Posts (Atom)
