Adam Kolawa of Parasoft Corporation

Equation 2: Increase Code Knowledge

2010-06-07T08:53:00.000-07:00

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.

Equation 1: Have a Clear, Actionable Plan of Attack

2010-05-19T14:27:00.000-07:00

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.

Equations for Efficiency

2010-05-05T16:04:00.000-07:00

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:

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.

Adding Developers Is Not the Solution

2010-03-29T14:55:00.000-07:00

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.

How to Calculate Software Development Productivity

2010-03-03T11:14:00.000-08:00

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.

Why Productivity Matters

2010-02-11T13:48:00.000-08:00

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:

Having a clear, actionable plan of attack = Productivity
Increasing code knowledge = Productivity
Reducing rework = Productivity
Reducing debugging = Productivity

Software Development Management

2010-01-14T09:34:00.000-08:00

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.

Rethinking Software

2009-07-29T10:10:00.000-07:00

Forbes recently published Rethinking Software, an article by Ed Sperling that explores why writing and fixing applications remains a persistent pain point for most companies.

The article interviews Adam Kolawa, CEO of Parasoft, leading provider of automated solutions and infrastructure services that improve software quality and the development process. It begins:

One of the biggest problems at any corporation is software--writing new applications, fixing old ones and modifying all of it to run on new hardware or interface with new technology.

It can take months to get a new application written, and in many cases no one wants to even touch the old software for fear of breaking it. So what's the solution? Forbes caught up with Adam Kolawa, CEO of Parasoft, to talk about what's broken and how to fix it.

Forbes: Why is it so hard to get new applications written at companies?
Adam Kolawa: The main problem is productivity. Anytime people want to change anything in software they're afraid of it. IT departments are not responding fast enough to the changing environment, and they are not supporting decisions of the CIO.

Are you talking about enterprise or productivity applications?

It's both. We need to reconfigure all software. Software is everywhere now. It's in cars, consumer electronics and IT systems. The problem is that we haven't figured out how to industrialize the methods of writing it. If a custom application for IT has about 1 million lines of code, they have about 50 to 80 people working on it. That's pretty standard in the industry. You get about 10,000 to 20,000 lines of code per developer. That's the horizon of productivity and understanding.

So how do you increase that?

Productivity depends on better understanding the code you work with. No one writes software from scratch. It's like remodeling a house instead of building it from scratch. You don't have the same kind of opportunities to change things when you're remodeling as you do when you're building it the first time. You write a little bit of software, which connects with another piece you have.

Do we need more code then?

No, and that's a secondary issue. We should have people who understand better the code they work with. Over the last 20 years the number of lines of code has stayed relatively constant. We thought we would have better programming languages and better descriptions, but we didn't get very far with this. Where we did make progress is with Web services and [application programming interfaces]. The problem is that too many developers are still trying to write software from scratch instead of creating modules and re-using them.

Wasn't that the whole idea behind object-oriented programming in the 1990s?

Yes, and it failed. But Web services actually are working now. So we are progressing in our understanding of how to construct software. All of this is related to standards. If you don't have standardization you don't have progress. The moment we had standard buses and interfaces on chips, we started to make progress. In software over the past four or five years we have developed standards for software and Web services. If you go back in the history of computers they couldn't talk to each other. TCP-IP allowed them to talk to each other, but the computers couldn't understand the message. With XML we have the ability to exchange messages between computers, and now the computers do understand each other.

***
Continue reading the complete article at forbes.com or parasoft.com.