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

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