Building code would seem to be a very straightforward technical task that would be done best by your favorite computer geek. There isn't much that would seem to be dependent upon personality and psychology in the workplace. However, the workplace is populated with human beings who use different communication styles and are filled with emotion and often quite fragile (and needy) in many ways.    Implementing repeatable build processes touches many of these key personality points as you interact with the developers who wrote the code and may have strong feelings about how their creations should be handled. Misstep and you find yourself not getting much cooperation from key stakeholders who can significantly impact your personal success or failure. Read on if you want to learn more about some key people skills essential to appreciating how and which personality factors which most impact one's ability to successfully implement core build and release management practices.

Separation Anxiety
Psychologists tell us that it is normal for children to feel some level of anxiety when saying goodbye to a parent, sibling or other individual. This becomes known as a separation disorder when the anxiety is so severe that it results in consistent symptoms which significantly disrupt the child's ability to function. I will resist the urge to go into more detail on this psychological problem other than to point out that some developers actually exhibit a mild form of this anxiety when being asked to part with their computer code so that it can be built by an independent team as is required by compliance regulations. Many developers feel far more secure when they can build and deploy their code to QA, UAT and Production themselves - all from the convenience (and safety) of their own desktop. Trying to retrain these developers to prepare their code to be built by an independent third party can result in many interesting behaviors ranging from the mild passive-aggressive obstruction to outright hostility. The first step in managing a build function is to realize that this behavior is often just a manifestation of anxiety, which can sometimes be remediated with good communication, and even better, collaboration.

Loose Cannons
In the book, Configuration Management Best Practices: Practical Methods that Work in the Real World, that I coauthored with Bob Aiello, I discussed the “Loose Cannons” who don't want to conform and follow the rules. Similarly, we discussed the “risk takers” who thrive on taking their chances – often with fantastic success. Technology professionals who refuse to follow the rules are often called cowboys with their development organization being described as the “Wild Wild West”. Aside from the glamour of lving in the Old West, cowboys may not make very good technology professionals. For example, developers who resist following the necessary controls to support the independent build process, may very well present significant challenges. They aren't the only ones. Some strong “process types” may exhibit their own challenges.

Highly Organized Personality Types
There are also very organized personality types who prefer their own internally created systems to those   suggested by others (CMBP, page 156). Obviously these colleagues can prove very difficult to deal with when trying to get them to follow build procedures. It is not uncommon to find people in the workforce struggling with OCD (obsessive-compulsive disorder) or Asperger's syndrome (a high functioning form of autism) who may be very rigid in wanting to follow only their own internally developed “standards.” You may find these people to be very difficult to work with.  In fact, people with a high need for “sameness” are frequently drawn to the IT field because of it's focus on order and concrete parameters. While you not are expected to diagnose these disorders, lots of people are actually very open and willing to discuss these challenges which can be compared to disabilities not much different than someone who is dealing with getting around in a wheelchair or on crutches. The lesson learned here is that when you suddenly notice that someone seems extremely difficult to work with, there may be very valid and rational reasons for their behavior, reasons which can be ameliorated with open discussion and minimal adjustment.

Communication Styles
To achieve success in implementing build management essentials, you need to consider and accommodate different ways of communicating. For example, many experts note that men and women communicate differently. Facilitating collaboration among diverse individuals may require different strategies for bringing out the best in each stakeholder to ensure the success of the entire team.

Resistance to Change
Resistance to change comes in many forms and may require some flexible skills to overcome. Kurt Lewin's well regarded change model includes three main phases: “unfreeze – move – refreeze”. The unfreeze step involves finding the key to successfully convince a group or individuals to adopt a new set of practices. Significant events such as failing an audit (possibly impacting your year end bonus) often causes organizations to reconsider their current standard operating procedures and provides the motivation for change. Once the new build management processes are implemented, you typically want to “freeze” them in place using a workflow automation tool (providing traceability and repeatability).

Productivity and Quality are Essential
Build engineering has a strong focus on automating builds which obviously results in improved productivity and quality. While many developers view the build process as “slowing them down”, the truth is that it is essential for Build Management to speed things up, although with a steady focus on ensuring that all processes are both repeatable and fully traceable.

Conclusion
Build Management Essentials are core practices and processes that can significantly help you achieve achieve success along with better quality and productivity. Enhancing your repertoire of  essential people skills will help you be able to work with all of the key stakeholders who are responsible for making this effort a success!

Trackback(0)

TrackBack URI for this entry

Comments (1)

Subscribe to this comment's feed

Ben Weatherall said:

... Nice article! From a technical standpoint over the years, I have seen behaviours that may fit within your categories, but are worth mentioning anyway. (1) Changes to third-party dependencies without notifying (or coordinating) with Build Management (BM). Depending on who you talk to, this can be considered a modification of the tool-chain or just another piece of "source." The problem comes in when trying to verify license compliance and ensure that "only one release" of each of these is in a product. Imagine having 5 different versions of swing in your Java app. (2) Upgrades to the development tool-chain (think JDKs and compilers) that are not reflected in the BM environment. It is not uncommon for BM to be blamed when a build breaks due to the dependency on some tool-chain feature that is not supported in the "official" environment. This has become even more of a problem since the advent of automatic updates to workstation environments. (3) "Ownership" of the build process by Development. This is typically more of a problem in organizations that are Development-centric, but it is not uncommon for developers to assume that BM is there to make Development's life easier and not to provide a control function. Over they years I have heard repeatedly, "Just click the build button! I do and everything works just fine..." (4) You mention the case where some developers do not want to turn loose of their code to BM. There is also the reverse case where developers hand off the code and it is up to BM to figure out what it is, where it belongs in the build process and indeed how to build it at all. There are two extremes for this attitude that I have run across - "The Builders are so good I don't have to worry about giving them the details," and "Hee, hee, let's see what they make of this!" At least in the first case BM can ask for help and get it when necessary, but in both cases it makes the job harder. (5) "Development solved the problem of build scripts by assuming ownership of them." This works to some extent, especially in a volatile environment, but the builds tend to be unstructured, non-modular and inefficient. And any problems are due to BM. From a skills set standpoint, most developers do not understand the build tool they are using, whether it is Ant, Maven or Make. The concepts of dependency-driven steps is as foreign to them as object-oriented development is to the typical driver of a car. And since Development owns the build scripts, there is not enough BM resources to truly analize and fix things when they go wrong.

report abuse vote down vote up

April 28, 2011
Votes: +0

Write comment