Drag Co-efficient of Software Development

The drag coefficient is a number that aerodynamicists use to model all of the complex dependencies of shape, inclination, and flow conditions on aircraft drag. This equation is simply a rearrangement of the drag equation where we solve for the drag coefficient in terms of the other variables. The drag coefficient Cd is equal to the drag D divided by the quantity: density r times half the velocity V squared times the reference area A. . . .

This equation gives us a way to determine a value for the drag coefficient. In a controlled environment . . . we can set the velocity, density, and area and measure the drag produced. Through division we arrive at a value for the drag coefficient. . . . [T]he choice of reference area (wing area, frontal area, surface area, . . . ) will affect the actual numerical value of the drag coefficient that is calculated. When reporting drag coefficient values, it is important to specify the reference area that is used to determine the coefficient. We can predict the drag that will be produced under a different set of velocity, density (altitude), and area conditions using the drag equation.

—From the NASA Glenn Learning Technologies Project Web site, http://www.grc.nasa.gov/WWW/K-12/airplane/dragco.html

How do you reduce the “drag coefficient” in software development? Well, the best place to start is to determine what is slowing you down. Much like an Olympic swimmer training for a race, software teams need to find ways of reducing the amount of friction pushing against their momentum—what is affecting overall cycle time—by optimizing their performance. Professional swimmers are constantly tracking performance metrics, identifying food and exercise variables that may affect their strength and endurance. They may occasionally resort to shaving their bodies, wearing compression suits, and changing their strokes as ways of minimizing their own drag coefficient. It takes dedication to get through the barriers that come with Olympic swimmers.

The same is true in Software Development Productivity. As software development professionals we need to look at our own productivity as well as our group and organizations. Just like swimmers knowing how to measure improvement is the first step. Second is knowing where to look to find improvements in productivity. Third is being self-aware enough to see what you typically don’t see.

First, metrics to measure productivity. Of course there have been several studies that measure LOC(Lines of Codes) per day, Defects/LOC, Story points, burn down charts, velocity, etc.. The list is long and can be confusing. So I am not going to add to the confusion except to say what ever you pick be consistent. Gather the metrics in the same manner each time you measure. Add additional metrics as you need to. Remember that time should be part of what you measure. Lastly, watch for trends and correlate them to changes that you make in your processes or tools.

Secondly, knowing where to look is a big deal. You can spend several weeks, months, or years looking at the wrong metrics, or focusing on something that doesn’t improve anything. My hints on this would be to look at the scope of where you are trying to optimize.

1. Personal change - There are some good resources for looking at your own personal software development process. The one that appears to be most eye opening to my is the Personal Software Process. It helps you look at how much time you spend doing certain tasks for get work done, Designing, Coding, Debugging, Building, etc... When I went through the exercises I found I was highly dependant on my compiler to find trival typos and coding bugs instead of just taking an additional 30 seconds to look first. I suggest reading through the book and taking the exercises.
2. Team Change - Areas that you can look for team productivity improvements can start with the interactions that you have with the other individuals in your team. This includes, meetings, code reviews, build times, defects, sprint backlog, velocity of task work, Build/Debug/Fix/Build turn around times. The benefit of working inside your team to look for areas of improvement is your team is relatively focused on delivering the same component/library. You all want to succeed together and the problem is typically scoped to a small number of people.
3. Organizational Change - When I talk about organizational change I am specifically targeting multiple teams integrated together to deliver products to the market. In this case most of the performance improvement has to do with team interaction, component and responsibility ownership, and communication channel effciency. So looking things like Defect assignment, Stakeholder decomposition and assignments of tasks to component groups, Number of integration build failures, Number of defects per Integration build, etc... The key here is to focus on how to improve the coordination of the work across all of the individual teams and the integration of such work.

Lastly, Is to be self aware. This is probably one of the hardest things that individuals, teams and organizations need to do to become truly effective. So let’s look at the swimming world to see if there is anything we can learn in the software world. Swimmers have used very complicated water tunnels to analyze their strokes. Although these have given some feedback, the most cost effective has been underwater video cameras. When swimmers can see how they look underwater they can make adjustments to their strokes and look at the effects those changes have on their times. Coaches can see and help swimmers but seeing it personally helps them understand what they are feeling in the water and what it looks like.

So how do we become more self aware developing software products. I don’t think setting up cameras in our cubes is going to help. But one method we might want to look at more is internal audits or assessments. If we look at this as ways to help us, instead of trying to just meet a criteria we can use the results to become more aware of our drag co-efficient. Even if we are doing a self audit like the PSP suggests. They all help us become better software engineers.

Who knows maybe we should do like the swimmers do and shave our whole bodies and wear compression suits while we code. But I dont think that will decrease the number of bugs I produce per LOC. :)

DWP