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

Truncated Domes, Code Reviews and Things that slow us down

Truncated Domes, Code Reviews and Things that Slow Us Down

I was recently at Target buying bedding for my family of 10 kids. Imagine a cart overflowing with pillows, blankets, sheets. The balancing act that it took me to put this all in the cart and get through check-out. As I come out of the store I can see my car three rows over and 5 cars down. I know I can do this. I just have to be careful and go slow and everything will make it in the cart to the car. Just for a second I take my eye off the sidewalk infront of me and boom! I hit those crazy yellow things in the sidewalk. You know what I am talking about the yellow bumps that are there to shake all of the stuff out of your cart. It is like someone does not want people to over stuff their carts. The bumps are there to shake everything loose out. Needless to say I spent the next 10 car.

Being an engineer of course I had to find out why in the world we have “Truncated Domes” in the front of stores at work, etc.. My first thought was someone slipped and fell. Then got a lawyer and sued everyone. Then companies afraid of being sued for millions put in the “Truncated Domes” so other people would not slip. Then I started getting mad at all of those lawyers that have caused my stuff to fall out of my cart. I had to look into this more.

Additional research found that truncated domes are a type of detectable warning areas as described in the Americans with Disabilities Act Accessibility Guidelines. Basically these yellow bumps help blind people know where the sidewalk ends and the street or parking lot begins. Many different types of detectable warning area techniques have been tried but the truncated domes have been found the most effective and the only type approved by the ADAAG. So I cannot get mad anymore. It helps blind people not walk into the street or busy parking lot. If I get mad at that then I would be unreasonable and very politically incorrect.

So what does that have to do with Software or Firmware engineering? I guess not much on the surface, but I did gain an appreciation for not taking things as they appear. Over the years I have found that some that one of the BKMs (Best Known Methods) to increase quality in software development is Code Reviews. One of the first reactions when Code Reviews are introduced to team is similar to my reaction to “Truncated Domes”. I hated them. Didn’t understand why they were there and knew they slowed me down. So to help people understand some of the benefits I have searched and compiled a quick list of benefits.

1. Sharing Experience and Knowledge - People come up to speed on new code faster when reviewing code of others. Teams talk about the code and tribal knowledge is built up.
2. Improved Code Quality - As people learn from each other they improve their own code. They want to make sure their code is higher quality when showing it to their peers.
3. Finding Bugs - As code reviews start at first bugs are found easier than after code review have been going on for a while. But it is much cheaper to find the bugs in code review than in validation or worse in the field.
4. Decrease Trucking Factor - As more people know and understand the code the team decreases the risk of losing domain knowledge due to illness, team moves, resignations or trucks hitting someone crossing the road.
5. Coding Standards - Coding standards are typically written down and new people spend hours reading documents that are difficult to understand. Code Reviews can bring people up to speed faster than sitting and reading coding standards.
6. Increased collaboration - Sometimes engineers need to be forced to be social and talk to each other. Code Reviews get engineers to talk with each other and share information.

Next time you are being feed a new process or tool you should ask yourself why was the tool chosen, what is the purpose behind it, and sometimes just trusting in the people making the decision. Next time I will talk about some of the tools that help in code reviews.

Helpful Links

1. http://www.gamasutra.com/view/news/37241/ - Benefits of Code Review
2. http://productdevelop.blogspot.com/2007/10/benefits-of-code-review.html - Benefits of a Code Review
3. http://www.zdnetasia.com/behold-the-benefits-of-code-reviewing-39172660.htm - Behold the benefits of code reviewing
4. http://ostatic.com/blog/open-source-code-review-tools - Open Source Code Review Tools

Published by Google Docs–Report Abuse–Updated automatically every 5 minutes

A Case for Software Coding Standards

I have had the unique opportunity of co-authoring three books. Each book was very unique in the way that it was published. As you would expect, by the time the third book was published, it was much easier than the first. However, you might be surprised why that was the case. Let’s take a look at what happened.
In 1999 I began co-authoring magazine articles for Rose Architect, a small magazine that talked about all things Rational Rose. This quickly grew into writing for several different trade magazines and publications. The main topic of the articles focused on software development tools and processes. After about 50 articles, my friend and co-writer, Christian Buckley and I decided we should put these together in a book. What an endeavor!
Our first decision was to self-publish the book. We found a printer, designed the cover, decided the size of the book. ( There is no standard size for technical books. They are all different sizes.) We gathered all of the articles together, categorized them and divided them into chapters. Next, we wrote introductions and conclusions for the chapters, transition paragraphs, a preface, a conclusion chapter and even rewrote some of the articles.
We had all of the content, text, graphics, bibliography, everything we needed for a book. We then spent the next 4-5 months working on the format so it was consistant and would fit on the size book that we wanted. We spent more time formatting and moving graphics, so they fit on the same page as the text, than we spent writing the content for the book. Our grand masterpiece finally went to the printer and we had the book in hand. Secrets of the Change Agent: Strategies for Software Development was born and we were the proud parents. Of course you can buy our book on Amazon. (Shameless plug)
Although the book did not make us the JK Rowlings of software engineering geeks, it did land us a book deal with a real publisher, Addison-Wesley. They wanted us to re-write our book to focus on Rational ClearCase Deployments. More specifically, how to use a system engineering approach to deploying ClearCase environments. This was the beginning of our next book: The Art of ClearCase® Deployment: The Secrets to Successful Implementation.
Now that we had a real publisher, we had to fit our writing style into their templates so their printer could automatically take the book and print it in their standard sizes, standard fonts, and font sizes. It took us sometime to learn the new template format and since much of our content was written in a different format, it had to be converted. Looking back we probably spent about 1/3 of our time formatting this book into this well defined standard from the publisher.
Within months of our book hitting stores, Addison-Wesley commissioned us to write a third book. This time on another tool from IBM-Rational. The tool was ClearQuest. There wasn’t a book out there yet on the tool and they liked the perspective we used in our other books. I had used the tool before, but was not an expert. By the end of writing the book, I would be.
We wrote the book from scratch. Nothing had been written before hand. We started with the template that Addison-Wesley gave us and started writing. Something amazed me this time. I spent no time at all worrying about formatting. I was already familiar with the writing standard and template they gave me. It was like second nature writing in that template. I focused all of my time on writing content for the book and making sure I understood the tool well enough to write about it. The book only took us six months from the first time we started writing to the time we were at the printers, three months shorter than the previous book. Our book: Implementing IBM® Rational® ClearQuest®: An End-to-End Deployment Guide is still considered the definitive guide to deploying Rational ClearQuest.
So what does this have to do with anything? I found it interesting that the final product was the same, a book. But the effort and time I spent on the actual content of the book compared to the formatting and style of the book overtime decreased and the quality of the book increased. My focus in the last book was the content. All of my creative energy was spent on the things that mattered, the content not the format, font size or color of the book.
I have found in my career when there is a well defined coding standard, development process, and tool chain, software engineers produce higher quality code in a more predictable manner. Their creative energy is focused on delivering the product not on the process of delivering the product. When teams have an ad-hoc coding standard, process and tools, the engineers tend to spend valuable time figuring out trivial things like: where to indent their code or what tool to use to share their code with their team.
Just my random thoughts.
DWP

An Argument for Software Coding Standards

Modern Day Carpetbaggers in Business

Over the years I have managed several teams all over the world. Dealt with different cultures, customs, timezones, and languages. Anytime I was dropped into a new role to replace someone that was there before,  I was seen as an outsider, a newcomer, someone placed into a spot that no one really wanted.
When I was thinking about what to name this blog I thought of my history teacher in high school when we talked about the civil war. When the north (upper management) placed people from the north to run the southern states governments (Middle Managers). This people were nicknamed Carpetbaggers. Because of the luggage they brought with them on their assignments. Wikipedia has a great article about the history and today's use of the term. Wikipedia: Carpetbagger.

When I think about how most middle managers are accepted into their new roles the term carpetbagger seems to fit really well. Everyone is looking for you to fail, suspicious of your motives, and do not trust the decisions you make. This can be a hard, but rewarding job. I am hoping that my ideas can spark a conversation about how to effectively step into these new roles and be effective as soon as possible.

This should be an interesting journey as I go back in time and look at all of the opportunities I have had to manage from the outside of a group and become a middle manager carpetbagger.