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.