Pages

Wednesday, January 22, 2014

It is a concept that seeks to remove the communication barriers between development, QA, and IT (operations). When all teams are communicating openly and effectively, the following benefits may be achieved:

shorter release cycle for new features

lower percentage of bugs that make it to production

better utilization of the organization's hardware and cloud resources

Is there a precedent for this concept?

In the 1990's, Toyota implemented a philosophy of "lean manufacturing" that reduced their production costs while simultaneously increasing their production line flexibility and their product quality. This is the same goal of the DevOps concept. Any software organization that has competitors (not all do) must constantly focus on staying competitive by reducing costs, increasing the product innovation, and reducing the relative percentage of bugs released into production.

What are specific issues that need to be addressed?

First I must point out that it is very difficult to change the behavior of groups of people when the behaviors have been entrenched for many years. For example:

If you are a developer, have you ever been frustrated with QA because they never seem to find your bugs unless it is 5pm on that same night that you plan to see your four year old daughter's ballet recital?

Or, if you are in QA, have you ever been frustrated with development because they never seem to give you a build until it is 5pm on the same night that you plan to reconcile with your girlfriend/boyfriend at her/his special restaurant?

Better yet if you are a system administrator, have you ever been frustrated with everyone because no one tells you of a major release until 5pm on the same night that you plan to go night hang gliding with a bright flashlight? (I ran out of ideas on that one...I hope you thought it was funny.)

The point is that most software development organizations are set up to keep the teams focused on their task at hand. Often, there is not much inter-team communication. Once the teams do communicate, it is often incidental or emergency event driven. Therefore, the fundamental change required to begin thinking in terms of "lean" or DevOps is to open communication between teams.

The goal of opening up the communication is to allow team members from each team to understand the challenges faced by each team. In other words, each team member should begin to understand that their team is only a part of the greater whole, the company/organization itself.

How can behavior be changed?

In order to bring about change in behavior within an organization, there must be a high ranking sponsor that can champion the change. There must also be a technical leader that is viewed as objective among the teams. This is often an architect, a release manager, or a technical director. The technical leader would work with the teams to identify tools and procedures that facilitate communication between the teams and visibility within the teams.

Beyond leadership, what else can drive change to behavior?

Tools. Tools act as the catalyst to change the behavior of the groups within the organization. The tools chosen must be capable of showing measurable results. For example:

DevOps may not be new to you if your organization has already been communicating across teams effectively and releasing products continuously with fewer bugs. However, there are still plenty of companies that have not had a need to focus on efficiency of product development. So, if you are a developer, a tester, a system administrator, a support engineer, a release manager, an architect, a manager, a director, a product owner, a business analyst, a sales person, or an executive in a company that does not focus on DevOps by name or otherwise, then you need to consider it. DevOps, the term, has been around since 2009 (as far as I know). DevOps the practice has been around since much longer. However, there are many tools that are now showing their value in the real world. This means that your competitors may be slowly converting to the DevOps approach or converting all at once.

It is my opinion that DevOps is here to stay. It is possible that the term may change over time, but the tools that facilitate the process are not going away. Furthermore, the companies that choose to make use of these tools will continue to evolve over time. Their competitors that do not follow the DevOps approach will likely not be able to keep up and potentially lose customers as a result.

Thursday, January 2, 2014

In 1991, I was just a co-op at IBM in Charlotte, NC. If you had asked me then about software design patterns, I would have thought you were talking about algorithms or data structures. At that time I was writing C and providing QA for a large banking image recognition project. Since then I have been exposed to 6 years of C++, 14 years of Java, 8 years of C#, 15 years of HTML, and 8 years of JavaScript. My employers have ranged from 4 different multi-billion dollar corporations and 6 different start-up companies.

Around the year 2000, I was working at a start-up where "speed to market" was the name of the game. However, I learned that if I keep my source code organized and easy to read, then I will be able to change it more quickly when the investors come around to tell us what the new direction for company is going to be (every six months, haha). I latter learned that I was following a practice known as separation of concerns (SoC).

By 2004, I was working on a large contract for the Department of Defense. This required a huge amount of interaction with many talented developers from all over the country. I was force fed the software design pattern of Service-Oriented Architecture (SOA) that brought 19 different DoD organizations together to share their data in order to fight global terrorism. At the time, there were aspects of it that felt like overkill, but I was happy to be able to follow the concepts and jump right in to help in the coding effort.

In 2007, I was leading my own team at Martin Marietta to design and implement a web-based product that would expose billing information to customers in a highly scalable manner. Based on my experience of the past, I decided to focus on using design patterns so that each member of the team would have a baseline for understanding my expectations for them. Therefore, I realized that design patterns would help me create a common dialog for which to build discussions about the problem domain. Furthermore, by using the patterns in the implementation, it was easier to split up the work among different developers. The project became very successful and is known as www.erocks.com. Erocks uses Spring MVC, a repository pattern (Hibernate underneath), and Inversion of Control (IoC).

The Point.

I could go on and on about projects that I have seen using patterns that have been successful. I could also tell you about a few projects that have been unsuccessful using patterns...but it was always due to a problem with funding or with business aspects outside of the control of development. Of course, there is the occasional misuse of patterns that cause great confusion and disarray in projects, but I have had only encountered that a few times in my career (thank goodness).

The point is that I am a huge fan of Software Design Patterns. Not because they sound cool (well, maybe only nerds think they sound cool). I believe that patterns allow us to get to what matters the most about creating software, understanding the problem domain and doing something about it.

Imagine that you are a gifted developer that always works alone and always remembers the frame of mind that you were in for every line of code you ever created. You would not need any design patterns in this case. You could always just say, "Hey, it works doesn't it!" However, if you are like me and can't always look at a line of code you wrote last year and recall the reason for it immediately, then you probably will benefit by having patterns.

Patterns also help with identifying the overall design strategy when architecting a solution. Odds are that there is another developer in the world that has already created your design but maybe it was not applied to your business domain. Why not take advantage of that fact and learn from the problems that have already been solved and resolved by hundreds or even thousands of others. This is what Patterns are.

Why Are Software Design Patterns Important?

Software Design Patterns are important because they facilitate a baseline of communication among teams using common terms and concepts, they provide a foundation of solutions to be used in solving problems in new domains, and they allow implementations to be assessed in terms of meeting an established expectation or standard. The bottom line is that these benefits save money for the company and save time for the developer.