5 Minute DevOps: Developer Misconduct

In the 1993 movie “Malice,” Alec Baldwin's character, Dr. Hill, is being sued for malpractice. When asked, “Do you have a god complex?” Dr. Hill responds with something that sounds eerily familiar to the attitudes of some peers I’ve come across in my career:

“I have an M.D. from Harvard. I am board-certified in cardiothoracic medicine and trauma surgery. I have been awarded citations from seven different medical boards in New England, and I am never, ever sick at sea.

You ask me if I have a God complex? Let me tell you something: I AM GOD!“

After nearly three decades as a developer, I’ve made my share of mistakes. However, I have always known my role was to help my organization achieve our goals rather than indulging in the vanity that I am the most important person in the room. I speak frequently about ways to make delivering value easier and rail against poor management who abuse developers. However, some of our peers do things that encourage mistrust, and we need to push against that, too. The following are real stories of developers putting their egos ahead of the organization’s goals. If you recognize these behaviors, call them out. If these strike too close to home, you may want to reflect on that.

“I Like My Style Better”

My first job was developing and customizing commercial logistics software for our customers. Customers who purchased our system were entitled to free upgrades for our core system. We also provided upgrades at an hourly rate for the parts of the system that we’d customized for them. They also had the ability to make in-house customizations, and our hourly rate covered that as well. For the upgrade process, we identified the delta in their source control and estimated the upgrade costs.

I was asked to provide the level of effort to upgrade a customer’s system to the next version of core, so I ran our script to identify the differences. I discovered that every source file in the system had been changed.

To make it easier for our developers to move from customer to customer, we had well-defined coding standards. The customer had hired an in-house developer who didn’t like our coding standards. They reformatted every file in the system to match their preferred style. For example, every conditional in the system was reformatted from:

IF [condition] 
THEN
[action]
END IF

To:

IF [condition] THEN
[action]
END IF

This type of change was made to every while loop, switch statement, and every other flow control structure in the system. Thousands of files of diffs. I punted to my management to negotiate with the customer on the unexpected upgrade expense. I can only assume the customer took over the upgrade effort because I never heard about it again. I’m sure the customer found these formatting changes enhanced the value delivered to their business. I can only hope that the developer responsible became enlightened.

“I Want to Learn!”

In another company, I was helping a team move to a continuous delivery workflow. Part of doing that requires a deep dive into their testing and architecture to identify improvements. The team’s current application was written in a combination of C#, Java, NodeJS, and React. When we reviewed their current application and plans for the future, they told me they planned to write their next service in Python. When I asked why they wanted to add more complexity to their tech stack, they answered, “We want to learn Python!”
Yes, we should be continuously learning, and much of that learning should be happening while we do our work. However, learning at work should be focused on delivering better value for the organization, not learning another language for the fun of it at the expense of business goals, stability, quality, and maintainability. I’ve experimented with building something in a new tech stack, but only as controlled experiments and only because we intended to phase out the old stack. In their case, the platform lacked good support for Python; none had experience with Python, and the language was rarely used elsewhere in the company. They just thought it would be “cool.” If our motives are not focused on value delivery, we should do those hobbies at home.

“Optimize for Me!”

A community effort I’m involved with is MinimumCD.org, a community effort to boil continuous delivery down to the minimum set of problems to solve to achieve CD. The value of the site is the content. The technology to present the content is largely irrelevant as long as it works. The site is built with Hugo, one of the many options for building static documentation sites. Minimalism and ease of maintenance are things the core team appreciates. The site has received hundreds of pull requests, either signatures or content improvements, with no complaints about being difficult to update.

Not long ago, a developer submitted a pull request to replace Hugo with another platform that uses React instead of Go templates and plain HTML because it’s more “modern.” The pull request consisted of 464 files changed, including renaming all of the content files. When we asked why this change was being suggested, the value proposition was:

• Enable rich content, such as animated examples of trunk-based development
• Make it easier for React developers to contribute to the project
• Make it look more “modern”

We provided the following feedback:

1. The content is the value proposition, not the framework to present it.
2. No one needs framework knowledge to contribute to the content.
3. There’s no need for animation on a site focused on minimalism and no indication that anyone was interested in building that.
4. The new framework was a beta release, so it wasn’t “more modern,” just less mature, and it increased the number of CVEs from 0 to 22.
5. It added maintenance toil for the core team to keep JS dependencies current where no current need exists.
6. Most importantly, the PR renamed all of the content files, which made code review impossible and destroyed the chain of evidence on the content we maintain.

We closed the PR without merging after a long conversation and thanking them for their passion. The developer took this poorly and became abusive, edging on bullying because we didn’t recognize the value of optimizing our community’s project to use something they liked more. Understand the value and contribute to the value. It’s not valuable simply because you did it.

“Look What I Built!”

The last isn’t one example but a pattern we frequently see: the ambitious developer who wants to be recognized for “innovation” but doesn’t have an original idea. Instead, they replace a working system with one developed using solutions they saw at a conference. Their solution solves the same problem but does it with technologies or architectures they aren’t familiar with.

A friend of mine had this happen where a developer convinced their management to let them replace the existing legal case tracking system with a new one using “modern architecture.” They got recognized and promoted based on their marketing and moved to a different area. When it was finally used, it was slower, less reliable, and used 50x more system resources.

Another example is the developer who wanted to be recognized for innovation by inventing a data lake and a brand-new interface protocol because REST and GraphQL were not innovative enough. Their efforts delayed features needed for data reporting and slowed down all future development by clients due to the lack of tooling and the confusing design of the new API protocol.

Neither of those examples was motivated by business value. Both were vanity projects. Even if they were focused on business value, they should have been controlled POCs, not replacements for things that worked.

Professional Misconduct

These are just some of the examples I’ve witnessed in my career. All of these have one thing in common: developers who are arrogant, entitled, and believe that their desires are more important than the organization’s needs. If they were self-employed, they’d quickly learn that indulging their vanity doesn’t pay the bills. However, they feel perfectly entitled to do things that don’t add value to the organization to satisfy their need to do things their own way. Our role as software engineers is to deliver valuable solutions to support our organization’s goals, not refactor working solutions to match our “style” or increase the complexity of an application because “I really want to learn QLang!” When you encounter people harming the organization that way, mentor them and remind them of their duty. If they persist, call out their misconduct and don’t enable them. If you are one of those people, re-align your ego to the outcomes you can create to help people live better lives with your products. Focus on the value being delivered!

My friend Tapabrata “Topo” Pal suggested this book to me after the conversation that inspired this post. I’m passing his suggestion on to you.

“The No Asshole Rule: Building a Civilized Workplace and Surviving One That Isn’t”