Thursday, October 27, 2011

An Argument 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

Monday, October 24, 2011

Agile Methodology: Yet another fad?

Throughout my career, I have seen several fads come and go in software development methodologies, tools and processes:

  • Structured programming, Object-oriented Development, Aspect-oriented development
  • Methodologies like Waterfall, spiral, iterative development cycles, Agile, SCRUM, CCM
  • Fully integrated development environments like visual studio, eclipse.
  • Languages like ADA, Fortran, C/C++/C#, Java, Groovy/Grails, .....

After years of management and organizational behaviorist trying and figure out how to harness the ever changing requirements of product development, dynamic competition, and the innovative energy of software engineers, they finally gave up! Gave control to the engineers! And we always deliver on time, with high quality, and with all of the features the customer wants. Ok not really, but with some of the new methodologies like Agile and SCRUM appear that way at first glance.

Agile is really not that new. The Agile Manifesto came out in 2001. Just after the great Dot Com boom and bust. The group that came up with the manifesto came from several different software anarchist individuals that wanted to give more power to the engineering teams and get away from the arcane methodologies that produced more paperwork than source code. Words like self-organizing; cross-functional, adaptive-development came out of this group of 17 software developers. The key values that the Agile Methodology focuses on are:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Many of these values fly in the face of micro-managers of the middle management ranks today. Think about the last time you sat down with your manager or director and they said they wanted a plan, documentation on how everything was to be done and then you could start doing your work. These software engineers came up and told management enough we know if we focus on these key items then we can deliver.

This great experiment in software development started to take hold and there are several case studies out there for agile development in small teams < 20 people. The same is not true for larger teams. Products that have large teams suffer from too many communication channels, distributed teams, and too many moving parts to keep control of. Although it appears that agile breaks down with larger teams, there are some groups trying to introduce agile methods and principles into large teams by mixing Methodologies. This is still a very new area in Agile and organizations are still trying to figure out how to make it work in a predictable manner. With companies being so data driven that is probably why it has not moved as quickly. Also many of our teams are larger than the 20 or so that agile seems to work best in. When was the last time you saw a development/validation team that was < 20 people. It does not happen very often.

One of the ideas that is floating around is a hybrid plan that allows for high-level planning, architecture and design, and allows for the smaller teams to value the four key values of agile, like working software, customer collaboration, responding to change and valuing the individual. The idea behind this methodology is to break the product up into components that can be developed, tested and delivered independent of each other. The combination of components together makes up a complete product which is delivered by an integration team that is agile itself. This is not an easy endeavor and requires great communication, face-face team, tracking of component and their progress, and trust. Let me say again Trust. Trust that all of the individual development teams are gathering requirements from their customers, other development teams, or the integration team. Trust that teams will deliver on time and what they said they would deliver.

I am working on writing up our experiences from this hybrid approach which should be coming in anthor blog soon.

Helpful links: