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

Changing your organization with the Stomach Flu

The Christmas holiday is always a time to meet with family and friends. This year was no different for me and my family. I had 2 of my daughters come home from school, one toting a fiance, (A blog for another time). Late night games with the older kids, early morning games and movies with the little kids. I wish they would get on the same schedule. The second half of our Holiday was spent at my parent’s house in Southern California. We arrived late on a Monday and my sister and her 5 kids where staying with my parents for a couple day overlap with us. Imagine all of those kids and adults in one house. Lots of fun lots of games, great conversation, and the spread of the stomach flu. Isolation was out of the question. Too many people and too little space to control it. It traveled like wild fire.

It started early Tuesday morning with one of my sister’s kids. Zero sleep for her and her husband. It quickly infected two more of her kids. Before noon on Tuesday 5 people were worshiping at the porcelain throne. Thankfully none of my kids had gotten it. We had can of Lysol  and anti-bacterial soap all over the place. We were fighting off this horrible unseen creature named viral gastro enderitus. None of my kids got sick on Tuesday and Wednesday was looking good. Until about 3pm on Wednesday when my youngest a 5 year old boy named David told me he stomach was feeling funny. With in 30 seconds we had a mess to clean up and a very sick little boy. 45 minutes later the next victim my 6 year old son. By 9 o’clock that night 3 more kids had already fallen to this nasty virus. My wife and I were the clean up crew and knew it was just a matter of time. By Friday morning when we were heading back to Northern California everyone but myself and my oldest daughter had or were still being effected by the stomach flu.

Of course the 500 mile 8 hour trip to Northern California took 11 hours because we had to stop several times. We were well equipped with throw up bags, ginger ale, and wet wipes, but we could only drive so far before we needed a break. In a very daring move my oldest who had not gotten sick taunted the virus when we stopped for lunch. She ordered the greasiest lunch she could find on the menu and said she wasn’t going to get sick. With in an hour on the road after lunch we had to pull over. It was like the virus heard her taunting and made her pay.

In the end this fast acting virus infected 30 people within a week including all of my kids, my sister and her kids and about 5 other families. So what does that have to do with anything about change in an organization? Let’s take a look.

Many of the effective changes to culture or process in an organization happens organically. It is very much like a virus. It replicates and spreads quickly and without prejudice. So let’s look at some key aspects to this virus and how it might be mimicked in organizational change.

1. It must spread quickly - When you have a change you want to make to an organization make sure that you can get it to spread quickly. Sometimes if you phase in your change it never takes hold in the organization. You may need to break up a large change into smaller chunks that are more acceptable to the org. We don’t want to kill the org we want it to be stronger after the change.

Have a plan in place. If you have multiple locations make sure that the change spreads in all locations at the same time. Otherwise you can easily get push back from one location that had not been “infected” yet. Make sure you find out who is most likely to spread the change around the most. Just like the virus attacked the youngest in my family first. You know the ones that don’t wash their hands and touch everything. You need to find the people in your org that evangelize the changes and aren’t afraid to spread it around.

2. It must overwhelm defences - Find out who has the lysol and overwhelm them with the change. Everytime you have a change there will be people that will push against it. It is human nature to keep things the same. Change is hard for people and the longer something has been the same the harder it is to change. So find out who is subverting the change and bring them on board. Let them know that the change will benefit them in the long run. If that doesn’t work then you need to surround them with peers and friends that have already been infected. And last measure and least desireable is to mandate it from above. Work with their manager to help them understand the benefits of everyone getting on board. Again last resort is to do this.

Another way of overwhelming an organization with change ties into spreading it quickly. The fast the better. Hit them fast and hard. Make sure that you have your supporting documentation, evangelists, and marketing talking points ready for the change. If you are in the middle of the change and still trying to come up with this you are too late. You need to make sure that you disseminate the information as fast and as in depth as possible. you need to overwhelm the organization. They need to see that the change is inevitable.

3. Close proximity increases the spread - I am sure if I didn’t take my family down to my parents house we would not have gotten that flu. We had to be exposed to it. We had to shake hands, eat dinner together, have fun together. This is the same in your organization. You need to get personal with your organization. They need to know that you have the best interests of the organization first. You need face time with your team and the key players of the team both your evangelists and your taunters.

If your organization is multiple geographies. Which in large organizations tends to always be the case. You need to make sure that you spend time in all of your locations and you need to get evangelists in all of your locations to help spread the change. You also need to identify the taunters and understand their concerns to help them overcome thier resistance to the change.

4. Infect the taunters - My daughter thought she had it beat. She tempted the virus and in the end the virus got her. You need to find out who in the organization will be or currently is most against the change. Identify and then use the overwhelm techniques described above. It is best to surround them with people they trust that have already accepted the change. Don’t leave this to chance. You need to work hard and see how the change is spreading and identify them quickly.

5. Make it viral not bacterial - Doctors have told me that if I have the virus it just needs to run its course, but a bacterial infection can be fought with antibiotics.  So what are the antibiotics of organization change. One of the most effective is upper management. Make sure you have upper management support for the change. Make sure that they stand up for you when the taunters come to them and complain that they don’t want to change. If upper management won’t stand or waffles on the change then the change is at jeopardy of not infecting the whole organization and you get bifurcation of the org. This then starts the multi-camp yours and mine mentality that can destroy an organization.

Another aspect of viral infections is that the host cells are used to produce more virus. You need this to happen with your change as well. You evangelists are key to this. They need to recruit more people to push the change in the organization.

Of course there are always those that will one to get their flu shot to prevent from getting the virus. Just like a virus your change needs to be able to mutate to infect the org. Good luck trying to figure that out. That is what makes you a great change agent.

Good luck infecting you organization with change. Remember if you don’t want to get the stomach flu yourself. stay away from people that have, wash your hands often and keep your hands away from you mouth. BTW, I was the only one in the house that didn’t get the virus. I think it was just dumb luck.

DWP

How to peel a banana and build software

Did you know there is more than one way to peel a banana? I had no idea, but due to the internet and my 10 kids, I have now learned no less than 9 ways to peel a banana. Here they are: human, monkey, snap, throw, four split, upside down, thuimbnail, twist, break and peel, and slice and peel. Many of them are just adaptations of 4 of them and one of them uses a knife which with 10 kids in the house is something we actually frown on. Image little kids running around the kitchen with knives and bananas. Not a good sight. The techniques that we use the most: Human, Monkey, Snap and Throw.

1. Human - Most popular, Grab the top of the banana (the part with the stem), grab the banana with your left head and grab the stem with the right hand and peel the stem back. Simple and most people (humans) peel bananas this way.
2. Monkey - Best for ripe bananas and children under 5 or monkey as we call them sometimes. Grab the bottom of the banana with you thumb and index finger squeeze the bottom of the banana with your two fingers until the banana splits. Peel and eat.
3. Snap - Great if you have more kids than bananas. Hold the banana in both hands like holding the handle bars of a bike. Move you hands close together. Do not squeeze the banana too hard. Not rotate your hands in opposite directions The banana will snap in two. 5 bananas can feed 10 kids. Or tie them over for a short period of time. My 5 year old son loves doing this, it makes him feel like a He-Man.
4. Throw - Best for the beginning of a food fight. Use with caution. Grab the stem of the banana in your throwing hand. Hold on tight and make a throwing motion while holding on to the steam of the banana. This takes practice and lots of squished bananas. Sometimes if you don’t hold tight the banana flies across the room. At least that is what I have told my wife when bananas start flying.

Each one of the techniques has the same end result a peeled banana. Although the techniques are different, the results are the same. So why have so many different techniques or methods? I liked the Human the most, because that is what I grew up with. But the Snap and throw can be fun at times. What does that have to do with Build Systems? Just like bananas there are many of them and they all end up with the same results. Software that is executable.

So what is your favorite software build system. There are several techniques and methods. Why do you use the one you have right now? Have you looked at any other ones? Have you broadened your horizons? Or are you stuck with an old system that no one knows how it works and everyone is afraid to change it? I have been in the position myself. Any way here is a list of sites and tools to get you thinking about something different or maybe you will become more enamored with your current Build System.

Build Systems can be broken down into different categories

• Build Scripting languages - Makefile, Ant, Maven, csh, bat
• Integrated development environment builds - Eclipse, Visual Studio, Netbeans, IntelliJ,
• Automated script generators, GNU Automake, CMake, qmake, nmake
• Continuous integration build systems, Jenkins, BuildForge, Bamboo, CruiseControl,ElecticCommander, etc... Click here for an complete list
• Release Management systems - Maven, ClearCase, Perforce, Jazz SCM, Git
• Build Avoidance systems - ClearMake, Maven, Ant, Meister

Other areas that tend to be grouped into the build systems because of the automations are:

• unit level testing and  - List is too long check out this site
• automated software configuration management systems - Perforce, RTC, ClearCase UCM, etc...

I hope you have broadened your horizons a little and see that there is so much more out there that can be leveraged to make your software development experience more productive. And maybe have fun peeling bananas.

DWP