What's in a name - Utopian Development Ecosystem

We are in the process of changing our way of working in our group. Many times when you are trying to effect large change you need a new perspective. You need something new to get people excited about the change; a new name. Companies do this all of the time. They spend millions of dollars coming up with new names for new product launches. So in an effort to give my team a fresh look at things, we came up with a new name for our development environment. The Utopian Development Ecosystem, UDE for short. Of course, we are engineers and need three letter acronyms for everything. This is a change from the standard “Development Environment” that we constantly talk about.

Let’s breakdown the new name, first Utopia. Thanks to Sir Thomas Moore we have the word Utopia from his book, “Utopia” (1516). He describes a perfect idealized society possessing highly desirable or perfect qualities. Everything in Utopia is in balance. Sounds like exactly what we were aiming for, perfection. If we are going to name something let’s pick the best.

Next let’s look at the word ecosystem. Wikipedia defines ecosystem as:

A community of living organisms (plants, animals and microbes) in conjunction with the nonliving components of their environment (things like air, water and mineral soil), interacting as a system. These components are regarded as linked together through nutrient cycles and energy flows.

What does this have to do with developing and delivering a product? It sounds more like a description of the ecosystem that is growing in my refrigerator, than a team of software engineers trying to deliver a product. If we are focusing on delivering a product let’s make some changes to some words that fit our situation.

• living organisms → People
• non-living components → Tools
• nutrient cycles → Guiding Principles
• energy flows → Processes

With these substitutions we get a new definition of ecosystem that fits our situation much better.

An Ecosystem is a community of people, (Developers, Validators, Architects, and Managers), in conjunction with the tools of their environment, (things like computers, storage, labs and cubes), interacting as a system. These components are regarded as linked together through guiding principles and processes.

Therefore, our perfect development ecosystem is all about people and tools and how they interact and are linked together through guiding principles and processes. This fits well with what we want to accomplish with our new development environment. It broadens the scope of the typical development environment to include guiding principles and people. Things that easily get overlooked.

Our Utopian Development Ecosystem defines everything we want to help our team deliver products. This has deep meaning and invokes strong feelings, but is simple enough for us to get the team to rally behind it.

DWP

Strawberries, Chocolate and Tomatoes

Recently my wife and I decided to try an experiment with 7 of our children. Each child got to pick out their favorite ingredient for dinner. It could be anything they wanted, but it had to be a single ingredient. They were all told their favorite ingredient would be put into dinner that evening. They all wrote their ideas on a piece of paper. No one knew what the other person wrote down. The challenge for my wife and I was to use all the ingredients to make something for dinner.

So here's a list of ingredients, starting from youngest to oldest child.

• strawberries - very good choice
• maple syrup - another great choice
• chocolate chips - sounds like a yummy dessert
• coconut milk - again a great combination
• olive oil - this is no longer dessert, it’s something else
• tomatoes -fits well with the olive oil
• parmesan cheese - the finishing touch

We had bow tie pasta planned for that night so we made 2 batches. One batch with chicken alfredo, the other with the concoction of favorite ingredients. The results were amazing....amazingly gross. All of these individual ingredients were great, but together a gastronomical disaster.

At work I have noticed the same sort of thing with development tools. If we don't spend time looking at the big picture, we can sometimes end up with great point solutions that combined together make a less than desirable system. A great build tool combined with a great configuration management tool adding in a requirements management tool can be great as long as they can all talk to each other and use a common systematic data model. If not, then you end up with a Frankenstein system that is hard to manage and not too pretty to look at. Some simple planning upfront with goals and objectives for each of the ingredients, can quickly change disaster into a utopian system.

First, focus on a common data model. This does not mean a single database, just a common data model. That means that when I say the word Defect, it means the same in all of the tools, has common fields and if possible resides in one place.

Second, focus on integration of tools not through replication of data. Replicating and translation of data always leads to problems. It is far better to link data across tools with as little data manipulation as possible. If a tool already has a notion of defect that does not match your primary tool for defects, then you can have a problem. Where is the real defect?

Third, remember the “best of breed” tool that does not fit into the system well, does not belong in the system. No matter how good the chocolate was that went into our family’s dinner, it tasted horrible with tomatoes and olive oil. The same is true with point tools that cannot effectively talk with other tools.

Last, look for the low touch integration. Just like in a well designed system you do not want to have a highly coupled tool integration suite. It causes problems when tools are upgraded. Look for loose coupling and high cohesion in the tools that you integrate together.

Good luck with the tool soup you are creating, remember that not all great things thrown together are necessarily a good combination.

DWP

Change Escape Velocity for an Organization

I was recently measuring how long it took for an idea to move through our organization. I compared several ideas over the last 3 years. I Looked at why some seemed to hit some critical mass and then just take off, while others required constant care and feeding and took a long time to be adopted. Reviewing the changes with my boss, he said there seems to be some escape velocity for ideas in the organization. Of course this made me want to investigate this more. At the suggestion of my boss Bradley Mitchell, I opened up wikipedia and took a look at the definition of escape velocity. This is what I found out:

1. Escape velocity changes depending how far away from the surface you are.
2. Escape velocity decreases with altitude.
3. It is the speed at which an object will not fall back to earth.
4. An object at any speed as long as it has propulsion, can escape the earth’s gravity.
5. If propulsion is removed on an object that is below escape velocity it will fall back to earth.
6. If an object is at or above escape velocity it has enough kinetic energy to “escape.”

There is also a formula that allows us to measure the escape velocity of any object.


G = gravitational constant
M = the mass of the planet or star
r = the distance from center of gravity.

So if we apply this to organizational change we get some interesting observations that seem to be true.
G = Change Constant
M = the size of the organization
r = how close to core values that change are.

So if the organization is large (large M) it will take more velocity to get the organization to change. If the change is far from the changing fundamentally core values of the organization then the escape velocity is smaller than if it profoundly affects core values. This seems to make some sense. I also think we can play with the Change Constant and say that it is not constant but corresponds to how old the organization is. The older an organization the harder it is to change and therefore the escape change velocity is higher.

Let’s look at these principles and see how they might apply to change in an organization. So how can I use escape velocity observations for escape change velocity?

1. The further you are from a profound change to core values the easier the change.
2. Change is easier for smaller changes.
3. To make a change permanent you must achieve the escape change velocity or it will fall back to earth.
4. Adding constant pressure to a change, will eventually make it stick.
5. If a change is launched without enough velocity to escape, it will revert back to its current situation.
6. If a change has enough velocity at launch, it will not need constant pressure to succeed.

As you can see the engineering side of me wants to put an equation to describe how I can help an organization change. But it is never that easy. Human beings are unpredictable and in a large organization with hundreds of individuals it is closer to chaos. The key is to try and determine what things can help control the chaos during the change. Finding the perfect velocity of change for the organization is a combination of the amount of change and the size of the organization.

DWP

Someone to Watch Over Me

In my work as well as at home it is always nice to have someone help me get my todo list done. Whether it is a honey do list or a work breakdown structured list from work, it is nice when I have the chance to have another set of eyes to make sure I did everything. Of course I didn’t think this applied to my honey do list, but my 6 year old son taught me something interesting this last week. I have been trying to fix our trash compactor for the last month or so. The problem is it is just hard to open the door. First thing I did was pull all of the garbage that fell behind the trash bin. That seemed to help some, but it was still really hard to open the door. Next I took the bin out and made sure all of the tracks were working fine. Then I started taking apart the wheel assembly. Putting it back together and tightening all of the screws. It was better but still hard. I was very frustrated and out of patience with this appliance from the underworld. Then my 6 year old son flipped the red switch that said,  “locked” to “unlocked,” and everything worked fine.

So, like a typical engineer I was looking for a hard problem to solve instead of looking for something obvious. This tends to be the case not just at home with household appliances, but at work as well. This could not just be for us engineers either. In the software engineering world there is a big movement to perform something called Pair Programming. Basically two people sit down to one computer and write code together. One person typing the other making sure the program is working, typed in correctly ,etc...

Can you imagine someone looking over your shoulder making sure you are typing correctly? Sounds annoying and it can be at first. But the results are huge according to some research that there can be up to 50% decrease in the number of mistakes (bugs) made in the code. Two people tend to consider more design alternatives, find bugs faster, and fix problems right the first time. I have used pair programming a couple of times in my career and in every case I have seen great improvement in hitting timelines, with higher quality.

However, I have also seen engineers not wanting to work nicely together. Maybe it goes back to elementary school when we are graded individually. Not as a group or team often. It is kind of funny. We teach kids in kindergarten to play together. By 3rd grade you are not allowed to share answers with your classmates, that is cheating. In fact one of the largest complaints about pair programming is who gets the credit. Especially when annual reviews come around. Somehow we have to overcome the social barriers that have been ingrained in us to not share or work together.

As I learned with my trash compactor, pair programming helps find solutions that would be otherwise overlooked. Even a 6 year old can see the obvious things that years of my domestic appliance repair was overlooking.

Patience and Patents

About 7 years ago I went through a patent harvesting exercise with my employer. It was 2005 and there was a big push in the software industry to patent everything they could. So they could be leveraged in licensing technologies between companies. The lawyer and my team submitted 14 patent applications and the waiting process began. About a year later I left the company and pretty much forgot about the patents. One day about 2 years later I got an email from one of the members of my former team. To my surprise,  we had been award 4 patents. Over the next year 2 more patents were approved. Not notice from my former employer. I found out thanks to “Google Scholar” monitor  (very cool tool that monitors your name and publications you have). Then silence; Nothing happen for 4 years and all of a sudden in the last 3 months 3 more patents were awarded.

I have lots of questions about the patent process. Maybe someone that has experience in this can give me some ideas.

• Why has it taken so long?
• Why does there seem to be some renewed interest in 7 year old patents.
• Do patent applications expire sometime?
• Is the high tech sue happy atmosphere today affecting number of patents filed and the time it takes to be reviewed? (Samsung and Apple for example)

With all of the renewed interest in my old patent applications, it reminds me of the old team I worked with, the cool technology we created, and the fun we had. So I guess the benefit of a long patent process might be nostalgia. I have lots of questions

DWP

Water Glasses and the Cost of Reuse

This summer my wife and I had a huge dilemma in our house. With kids home from school and the hot weather, our family of 9 ( 7 kids at home) was going through all of our glasses in our cupboards. We actually have more than 9 glasses, in fact we have plenty of glasses. But for some reason our glass cupboard was empty and our sink was full of glasses all summer long. Something about teenagers not being able to reuse the same cup more than once. In some respects I don’t blame the older kids. The younger kids, especially our 5 year old, just grabs any cup they can reach and gets himself a glass of water. If my 5 year old was not a walking magnet dirt, grime and everything sticky, I am sure the older kids wouldn’t mind to reusing the glasses sitting by the sink. So there is the dilemma, I have a limited number of glasses (supply), a fixed number of kids, at least right now (demand), and an unlimited demand for drinks of water. What a better reason to show the benefits of reuse.

Warning software geekiness alert!!!!

The costs of not reusing the glasses is very measurable. If I have to buy more glasses that costs money, more glasses probably means  more cupboard space as well. Not to mention more cycles of the dishwasher running. Another option is to limit the number of drinks of water per child per day. So reuse most definitely has a benefit. A measurable benefit. Money in my pocket. This is great. More money for my vacation fund or more than likely kids college fund.

Being the engineer that I am I started looking to see if there was a cost to re-use as well. It didn’t take long to find one of the costs of re-using glasses on the counter. All I had to do is open a bill from the doctor’s office.  Little kids tend to be petri dishes for germs and virus and anything else they pick up at school, the playground or a friend’s house.  And many of these little bugs spread like wildfire when we have reuse model of sharing glasses. Ok a bit of a stretch, but sharing is not always a good thing.

So what does that have to do with software engineering? Code reuse has been touted as the holy grail of software engineering. We always look at the benefit of reusing a component or code in a product. The benefits are great. Development team reduction, maintaining one component instead of multiple components, validation cycle reduction, etc... But what is the cost of re-use? Is there a cost? Just like the water glass situation in my house it depends on the design and architecture of the solution. The costs could be high or it could be low based on the what you value most.
There are different levels of re-use that should be explored. An article by Amber shows the different areas of reuse.

Architecture-Driven Reuse	·       The reuse and/or development of reusable technical and business components and services described by your enterprise architecture models ·       Sometimes referred to as domain-component reuse
Artifact Reuse	·       The reuse of previously created development artifacts: use cases; standards documents; domain-specific models procedures and guidelines; and other applications
Code Reuse	·       The reuse of source code within sections of an application and potentially across multiple applications ·       Includes use of Web services
Component Reuse	·       The reuse of pre-built, fully-encapsulated components in the development of your application
Framework Reuse	·       The reuse of collections of classes that, together, implement the basic functionality of a common technical or business domain
Inheritance Reuse	·       The use of inheritance in your application to take advantage of behavior implemented in existing classes
Pattern Reuse	·       The reuse of publicly documented approaches, called patterns, to solving common problems
Template Reuse	·       The reuse of a common set of layouts for key development artifacts – documents, models and source code – within your organization

Many times we just focus on the code reuse without considering the other areas of reuse. Ignoring these other areas can lead to increased costs. It may not always be the best thing to re-use product artifacts. I think we need to spend more time analyzing the benefits and costs before just jumping into something.

By the way, my wise parents (6 kids)  had a solution to the water glass problem. No reuse at all. They put a water faucet in the kitchen. No more water glasses in the sink. Reuse was just too costly and messy.


DWP

Learning to Ride a Bike (for the eighth, ninth and tenth time)

Three of my kids are learning how to ride a bike right now. Since my wife and I have already done this 7 times, we thought it would be easy. It has been 7 years since we have done it, but teaching someone to ride a bike should be the same as riding a bike. Once you do it, you never forget. So we lined our  5, 6 and 7 year olds up with their hand me down bikes from their older siblings and started their journey from little kids to big kids. We knew that these kids all  have different personalities with some  less coordinated than others, some are more fearful than others, and some are more stubborn than others. But we had years of experience teaching kids to ride bikes. We knew the routine, an hour of tears, some crashing, scrapes and bruises with Toy Story band-aids.  My wife and I both played our roles. I would say, “Stop crying and get back on the bike.”  “Everyone falls you just need to do it again.” And my wife with the, “I know it hurts, let me kiss it better”, “You did so good”, “You're ok, lets try again.” Both of us taking turns with the video camera and running behind them on their bikes.

You get the picture. We noticed a couple of things that were impeding my kids from just picking up the bike and riding it. They are what I call “barriers to riding.” Being the software engineer with an MBA, I need to have a buzz word or phrase to explain things. I will show a graph later with success in the upper right hand corner of the page. Funny thing is that I see similar things when it comes to engineers and teams evaluating and using new tools. In previous blogs, I have mentioned to find out what motivates people and how to play to those motivators. I have been reminded that we also have to look at “de-motivators” or “dissuadors”.  Here are some of the things that dissuade trying out new tools or learning to ride a bike: fear, complexity and complacency.

Fear
Fear is one of the most powerful, “barriers to entry”, there are.  Our society does not seem to help the situation. Look at kids learning to ride a bike. We completely cover them in helmets, knee pads, elbow pads, etc... We basically scare our kids and teach them to be afraid to ride a bike. We predisposition them that falling is going to hurt and may kill you. No wonder they are very scared to try and ride. We do the same thing in business. I don’t think if the new build system fails to build, will kill you, but we put the fear of trying and failing into annual performance reviews, development metrics, and tight release schedules.

After my kids all fell once or twice, they found out that it only hurts a little bit. They weren’t going to die.  They got the comfort they needed from their mom, the motivation from their dad and they kept trying. We did not reward them for trying and quitting. We encouraged and adjusted our approach based on the results we had before. The key was showing them that it was safe to fall and encouragement to keep trying.

We need to foster the same kind of atmosphere in our work environments. Encourage people to try new things, learn new techniques and use tools. We need to be okay with failing and learning to eventually succeed. We need to make sure that we don’t reward failure. We cannot remove the natural consequences of failure. Like my kids, they had to fall a couple of times before they could figure out how to balance. When we fail we still need the sting of hitting the pavement and skinning our knee, or we won’t know we are headed in the wrong direction and we cannot correct the path we are on.

Complexity
Everyone that rides a bike knows that it is easy. It is not that complex. Tell that to a 5 year old, or an engineer that has only used vi or emacs and cannot see moving to a windows based IDE where they have to use their mouse to get things done. (I fit into that category). To ride a bike it requires balance, hand eye coordination to move the handle bars, strength to push the pedals, coordination to move your legs in a new motion, etc.... For a 5 or 6 year old this can be very hard to figure out. Throw fear in there and you have something monumental to overcome.

One of the tricks we learned was to break down complexity, remove some of the factors that make it complex. Whether it is holding on to the back of their seat, (removing balance), or removing the pedals, (removing the leg motion and strength requirements).  This worked like a charm, and as they built up their confidence and coordination, they have progressed to riding their bikes all of the time. It has become second nature to them.

Same thing applies to adopting a new tool or process. Don’t do everything at once if it is too complex. It could be very difficult for an individual or organization to swallow all of the complexity at once. But remember, the end goal is to have the complete system in place. You need to put the pedals back on the bike to actually ride the bike. If you don’t, you can’t go as fast as everyone else riding their bike.

Complacency
My 5 year old told my wife and I that he can walk and that he does not need to ride a bike. Ok, this is actually true, but we had to show him the benefits or riding a bike compared to walking everywhere. First, so we can have fun with our friends; his response,  “I can ride my scooter.” Second, we can get to places faster; his answer was to drive a car. Third, we can go places on our bikes that our cars cannot go; his creative juices were flowing now, “We can use super hero powers and fly there.”

We run into the same problem in our organizations that don’t want to change. It is comfortable and familiar in a world that seems to always change. Most people want something that is always the same. So what do you do? Fight complacency with a plan and develop a sense of urgency. In the case of my 5 year old, our plan was to ride a bike and show him all of the steps we were going to take to teach him. Then, we had to give him a sense of urgency. So we planned some family bike trips to the park. One of his favorite parks. The urgency was there and the plan was in place.

Organizations need the same kind of strategic plan and urgency that my 5 year old needed. Without an end goal and a timeline to meet the goal with some kind of consequence, the people on your team might wonder why they are making the change. “Change for change’s sake” will be the mantra for the week, and the effort will be undermined by complacency.

Results
When a substantial change is made in an organization, you need to celebrate. There needs to be a reward for the change. Many times we forget to point out to our teams the benefits that have been realized from making the change. Don’t forget to point out the natural consequences of the changes. Many people need to be reminded. A celebratory pizza party helps sometimes as well.

As of this date we have 2 new bike riders in our family. My 5 year old is still holding out, but this next week may be the week for him. Like I said. We learn from our failures not our successes. Anyway it may give me more ideas for another blog.


DWP

Saggy Pants and Pointy hair: Motivating Teenagers and Bosses

I have a very unique situation. I have been climbing the executive ladder for years and finally reached the executive level. Recently, I moved into an individual contributor role where I try and influence an organization for change from the side of the organization, instead of from the boss position. It is a very challenging, role but at the same time very fun.  Trying to figure out  how the organization operates,  how it changes and what motivates it to change.  I also have another unique situation in that I have 10 kids. That is not binary for 2. That is the number TEN, and having a blended family with that many kids feels much like my job. Influencing the children with different ages from 5 to 23 years old, is just as challenging as helping an organization through change.  I have found some interesting comparisons:

Family	Work
One child can make an 8 hour road trip to grandma’s house completely miserable for everyone.	One person can torpedo the role out of the greatest process improvement.
What motivates my 5 year old son, does not work for my 17 year old sons.	What motivates the CEO is different from  directors, managers and individual contributors.
Not everyone can be heard at the dinner table when everyone is talking at the same time. But everyone wants to be heard.	Some of the best ideas for change can come in the ranks of the organization. At all levels.
Mom and Dad need alone time as often as they possibly can to recharge.	I got nothing here.

I would like to look specifically on what motivates. I am starting to understand what motivates my 5, 6 and 7 year olds. Treats and trips to the park. My teenagers are a bit harder, but it mostly has to do with electronics. My older kids are motivated by pure cash mostly because they need it for college or fixing their car. Organizations are somewhat similar and finding out what motivates individuals is key to effecting change. So what motivates you, your boss, or your boss’s boss?

Individual Contributors - Money is a good motivator for most individual contributors, but that is typically only the case if they feel they are not being paid enough. What I have found is a better motivator is, do they enjoy their work? Is it fun, is their voice heard, can they make a difference?  For some it might be the camaraderie of working in a great team.

First-line Managers – Many first line managers want to be directors and they want to climb that leadership ladder. So they want to make sure their team is successful according to what their director or senior manager wants. They are trying to make sure that themselves, and their teams, look good. They are building their careers. Then there are some first line managers that want to stay where they are. So they want things that are stable, quiet and secure.  When trying to effect change with first line managers you need to find out the type of managers you are dealing with.

Directors and Senior Managers – Power and influence. This is all about your team. The more successful your team is the more successful you are in the eyes of the executives. You have influence over more people, budgets and schedules. Being able to predictably deliver products or services from the organization is the key success factor of these people.

Executives – Motivators for public company executives are very different than motivators for private companies. Public companies live and die on quarterly revenue and profit.  Private company executives typically are motivated by long-term sustainable profit. How is a change in my organization going to affect my revenue and profit this quarter for public companies or longer for private companies? This of course is not always true and there are some executives with other motivation than the bottom line, but again you need to find out what motivates or de-motivates an executive to change.

Of course these are sparkling generalities and cannot be applied to every organization. The key is for you to find out what motivates people to change in your organization. Write it down. Then develop a plan to motivate your organization at all levels.

DWP

Rock Quarries and Build/Test Farms

When I was a teenager, I had a friend whose dad owned a rock quarry. They mined for aggregate that is used to make concrete, backfill for roads, and building subdivisions. It was a small operation, but for a teenage boy it was very cool. Large machines with conveyer belts, crushers, screens, and shakers. The engineer inside of me was fascinated with how it all worked. You dump in a truck full of what looked like dirt and rocks into one side of these machines and out on the other side came rocks of several different sizes, dirt and silt. The silt mixed with water made some of the best mud football games you can imagine.

The image of these big machines came to my mind when I was talking to a couple of engineers tell me about our software build, release and test system at work. The source code goes in one side and our product comes out of the other side. And in our case more than one version of the product targeted for different Operating Systems and or configurations. One of the things they were complaining about was the amount of time it took to find out if their changes broke the build or made it past all of the tests in the test farm.

Over the years the amount of tests run with each build has increased and the number of configurations has increased. This has made the turn around time hours instead of minutes as it used to be. The engineers I was talking to were complaining that they wanted instant feedback and could not wait hours to see if what they just typed in was going to bring the whole organization down or but the “magnus opus” that they believe they just created. Our build and test farm becomes overwhelmed when we are close to a release date and build results end up taking days instead of hours.

Again the big machines at the quarry came to mind again. I could see the huge screens, shakers and conveyor belts. I could picture how the first convey belt moved the dirt and rocks up to the top of this tower with conveyor belts coming off in all directions. The dirt then would be dumped into this very large screen big enough for almost everything except for large rocks about the size of large potatoes. These large rocks were sent down a conveyor belt to a crusher that then smashed these rocks into smaller rocks and then dumped that back into the top of the machine. The next set of screens would be smaller and let everything pass through except for rocks the about ¼ the size of the previous screen. In this case the conveyor belt carried these rocks to a big pile next to the tower of machines. This continued on until at the bottom of the stack silt was conveyed out to the silt pond. Did I mention mud football already?

I could see what the engineers were wanting. They wanted to know if their build had big rocks or boulders in it first. They needed a quick feedback smoketest. Well we already had that. But they also wanted the aggregate screen. They wanted product out before everything was screened through the system. So I did what most good engineers do I went to google and looked at the different levels of testing. I found a good powerpoint that shows the canoical view of levels of testing. http://www.cs.swan.ac.uk/~csmarkus/CS339/presentations/20061202_Oladimeji_Levels_of_Testing.pdf. Simply it can be desribed as.

• Unit Testing
• Integration Testing
• System Testing
• Acceptance Testing
• Regression Testing

As I kept looking further in my organization I found, Interesting enough, many of the groups started doing placing screens in their build/test systems themselves in an ad hoc manner with CI build systems. Jenkins and Berta seem to be the most popular. As I went around and talked to more teams and more engineers I found one group in particular that had the same vision of the rock quarry as I did but had it in Software build and test.

This group had set up a CI build system that took each check in and pushed the build through several screens of tests to see the quality of the build. They had 5 levels of testing that would occur with each build. The screens became mroe fine grained and would take longer to run at as the source and build would go down the stack. There are a number of screens that can be put in place to give the engineers a quick feedback loop that they are looking for. The key is to time bound the first level of screens. Using a mixture of the levels of testing to give the first screen nice coverage of build and give immediate feedback to the developers. Here is an example of how a nice build/test screen could be set up.

< Time	Name	Build	Test
10 minutes	Smoke Test	Incremental	High level integration, some unit testing
30 minutes	Check In Regression	Build from Smoke.	Unit Testing for CheckIn
1 hour	Integration	Full Build	Integration Test, Regression Tests
3 hours	Performance	Build from Integration	Performance Tests
6 hours	Nightly	Build from Integration	Integration Tests, System Tests, Unit Tests
36 hours	Weekly/Weekend	Build from Nightly	Full test suites. Performance

This of course is just an example of what could be. I think it is important to put a plan together on how the build progresses through the screens and in some cases the build is performance more than once on the same code base. Coordination between Validation and Development is key to making this work effectively.
Let me know what you think. Do you have any other good ideas on how to give development feedback quicker without sacrificing the quality of your product.

DWP

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