Equation 2: Increase Code Knowledge

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

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.

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.

Rethinking Software

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.