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.