Working With Citizen (Rogue) Developers

At my day job, I work a lot with citizen developers, a term I use here to describe non-software engineer business stakeholders who are empowered to write code to solve their business problems. Truthfully, I call them rogue developers with tongue in cheek because of the pain they sometimes cause our engineering organization, but citizen dveloper is the industry terminology that approximately describes them.

As a software engineer, the main source of stress in working with a rogue developer is that they are uninterested in the craft of software engineering: the long term process of a team developing and nurturing a technical system that solves a broad array of business problems and can be easily adapted to solve future problems. Instead, rogue developers may see their code purely as a means to an immediate end: an artifact that produces the desired output given some set of inputs. That is, while software engineering is building understanding, considering what can go wrong, and planning for the future; rogue development is purely about making the computer do right now what a human did before, or simply cannot do at all.

At my employer PEAK6, rogue developers are often traders, though they can be on operational teams as well, like Finance or Compliance. In my position, I might review a rogue developer’s code, but more often I come across it after it’s already out in the wild producing value, and I’m tasked with supporting it, modifying it, and making it fit into the broader socio-technical system.

Working with (and staying sane around) rogue developers has been a years-long growing experience for me, and though my description above could be interpreted harshly, they are immensely valuable. I thought I’d write down some of my personal learnings for others to ponder, which wall into a few broad categories.

Business Value

Don’t ever stop a rogue developer from writing code that solves a business problem when there are no other options. It’s important not to be seen as an impediment to real value, either by those outside or inside your engineering org. you can suggest (or possibly even demand) changing their code to solve the problem in a better way, but you should practically never shut them down entirely. Architecture of a system is important, but there is almost no way your opinions about architecture matter more than the real business value provided by the rogue developer’s code.

Why shouldn’t you show down a rogue developer’s effort? They are the business, they are the stakeholder! They immediately and intuitively know what is useful to them, it doesn’t have to be filtered through a product manager or a product-minded engineer and a too-long discovery and prioritization process. Never take this for granted.

Empathy

Have empathy for the rogue developer. They are not software engineers either by training or by experience. They’re unconcerned with maintainability or simplicity except to the extent that it helps them, if they don’t have experience modifying code after it was first written, especially code written by someone else. And it isn’t because they’re inconsiderate or self-centered - they might not even comprehend that these concerns exist! Most non-technical people period do not understand the main challenges of software engineering, and why would they? Getting the computer to do what you want (where software engineering ends, not begins) is alchemy in and of itself.¹

When giving feedback, explain why. Of course, we already do this with our peers, junior engineers. But with a rogue developer, when you say “don’t do this,” you might even have to explain that working code can even be “bad” in the first place, let alone why their code is “bad.” It’s impossible to overestimate how much experience you take for granted when communicating about code with a rogue developer.

If rogue developers are users of a platform you maintain, build the features they want, not just the features you want. Listening to your users is of course key for any platform engineer, but when building a platform for less-technically-skilled users, it becomes that much more important to understand what their needs are because they won’t be as good at articulating them. Make sure you’ve identified their real needs first, not just the needs you want them to have. Then let that shape your thinking about how to enhance the system to solve their needs. An elegant platform does no good if your users don’t understand it well enough to use it properly.

Prevention

As a software engineer, it’s your responsibility to protect a rogue developer from themselves, as well as protect your team and org and the systems they maintain. This doesn’t mean you should get drunk with power and shut down their efforts (see “business value”) at the slightest indication that their code could cause problems in technical or business systems. But it does mean you need to consider these questions and push back with clarity when appropriate. It could be on anything from irresponsible resource utilization, to accessing data through an unstable private interface rather than a supported public interface. As with software architecture, focusing on preventing decisions that are hard to reverse.

Keep rogue developer code on the edge of your system, not in the center, and be vocal about this. Encourage rogue developers to innovate on the edge where the blast radius is small relative to the potential business value. The most specific and valuable business logic tends to exist on the edge of a system anyway, while the core (which is harder to change) is more plumbing. If rogue developers are interested in changing or programming to the core of your system, it’s a sign that it’s poorly factored.

Sanity

Create a private slack channel where you can post snippets of rogue developer code that you and your fellow “software engineers” can vent about. Seriously. It helps. It’s not even mean-spirited: software engineers are well aware that “you are not your code” and that ribbing a rogue developer for their code quality is in no way a slight on them as a person or even their core abilities in their role.

Summary

Most of these lessons just boil down to having perspective, as well as personal and professional maturity as a software engineer. But it’s good to keep the high level lessons in mind:

• Rogue developers have a better sense of business value than you
• Their relationship to code and systems is different and that’s okay: seek to understand it!
• Prevent only obviously incorrect or hard to reverse decisions that have good alternatives