The Cowboy Coding approach is a fairly well known one in the area of software development. In its most basic form, it is the idea of the cavalier individual that has a propensity for aggressively tossing code over the fence, and hoping for the best!
There are plenty of writings on this out there on the WWW. For example, this article on Medium which explores this approach vis-à-vis innovation. An environment that permits this culture of behaviour, or indeed, (inadvertently, we hope) promotes it, tends to result in a landscape that resembles the Wild Wild West - i.e. not a particularly professional, ethical, nor sustainable one.
The Coding Bandit
The alliterative quality of the term is undeniable. However, perhaps a better phrase would be: the coding bandit. The true cowboy is the herder that works tirelessly as an individual and works well with fellow grafters, with the ultimate goal of supporting the family, and the broader community. On the other hand, the bandit is more of a self-absorbed desperado, who is fueled by a desire for financial remuneration and notoriety.
Aside: "graft" versus "hard graft"
Detection
So, what are the telltale signs that a Cowboy Coding individual or culture has infiltrated the organization?
Here are a few:
The Hero Persona: we all know the guy that prances around from team to team and who is well able to talk the talk. Perhaps his normal job is in the professional services department, or the like. The CTO will foist this clever citizen upon the unwitting engineering team to lead the effort of bringing some novel idea to fruition. Our "hero" (or antihero), is undoubtedly a skilled developer from a prototyping perspective. He's able to quickly churn out code and get it committed (with incredible ease, despite the PR review process that's in place) and get some stuff working, with precious little genuine focus on the edge-case requirements, non-functional requirements (performance, security, extensibility, etc.), and due diligence in terms of software testing. Once the "pre-alpha" is deemed a success, he's off on his way to be a hero someplace else!
Low Morale & Team Spirit: the root source of a broken team can sometimes be difficult to diagnose. Counterintuitively (perhaps), autonomy and lack of structure are very often the recipe for this deterioration (structure is very often misconstrued as a vehicle for stunting productivity and creativity, as opposed to its primary goal of bringing consistency to the process of building and delivering quality software). Havoc is inevitable if the Cowboy is allowed to do his own thing. Havoc not only in the codebase itself, but also within the team (and cross-team) dynamic.
Technical Debt: how often does so-called prototype code end up persisting through the entire lifecycle of a codebase? Or, perhaps more devastatingly, how often does prototype code become the exemplar pattern? Prototyping is of course an important part of the development process. The key is to ensure that the prototype code (which implicitly includes underlying architectural dependencies, design decisions, etc.) is subsequently fleshed out fully and held to the same standards as any other code in the system. Whenever there's a Cowboy in the mix, proof-of-concept type code tends to stick as is (like mud!). In my experience, this modus operandi is a prime source of technical debt in software systems.
Very often these signs are far more fuzzy than suggested above and can easily fly under the radar for quite some time. It's up to managers and developers alike to be vigilant!
Resolution
In the WWW, presence of the rat is advertised to all, and then the bounty hunters take on the challenge of capturing the culprit so that justice might be served and the WWW can become a slightly safer and more orderly place; until the next rat comes along!
In a software development organization, it is sometimes feasible to fire the antagonist. However, very often, the wrangler can simply move on to some other jurisdiction, or if the infiltration is too deep then this approach is not practical. The Cowboy is usually adept at ensuring high job security - brown-nosing with the C-level, plamausing the sales folks, and deceiving engineering managers and (perhaps also) peers.
Management and developers may well be aware that this rock star continues to moonlight from one team in the department to another, leaving an ungodly mess in his wake. But, it's quite the other thing to be willing and able to convince the powers-that-be of this reality.
Accountability
Continually fostering and demanding a culture of accountability and transparency is the only way (I believe). All contributors to the codebase must be willing to pony up in terms of accountability, regardless of longevity in the department and/or within a particular team, and regardless of ones label (be it "associate" or "fellow"). And let's not forget, as Kent Beck rightly highlights in this article, accountability is not to be mistaken for "the blame game".
