A Problem with Cowboy Coding

As we implement more automation and complexity in our systems, we increase the ability of every worker to accomplish more during their day. In many cases, this is a good thing, as many of us have no shortage of tasks to complete. Being able to do more is good. Some technology workers, and likely some managers, view these changes as opportunities to use less people to do the same work. That can be worrisome for many people, especially those concerned with job security. That’s a difficult situation to find one’s self in.

I’m not sure if this worker was concerned about losing employment or just wanted to get more work, but a contractor put logic bombs in his project that would cause issues at various times. He would then be called to fix issues, getting paid for his efforts. Recently he was sentenced to prison time for his actions.

Most workers make an effort to do good work and provide value for their time and knowledge. They may still make mistakes or cause problems, but it’s often unintentional, not malicious. We also don’t look to create future problems for others, though certainly we may accrue technical debt over time as we make trade-offs in our work.

Whether intentional or accidental, we want to limit mistakes and issues in our code. This is one reason that modern development in a DevOps environment isn’t a wild west, cowboy style of work. We use code reviews and continuous improvement to help other developers learn to write better code. We use automated processes with instrumentation and logging to ensure we know what code is deployed when and by whom.

We may move faster with DevOps, but it’s often safer, more secure, and more accountable than previous methods of building software. It doesn’t prevent mistakes, but every part of the process should be more transparent and auditable, which is good for everyone involved.

Steve Jones

Listen to the podcast at Libsyn, Stitcher or iTunes.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged . Bookmark the permalink.

5 Responses to A Problem with Cowboy Coding

  1. TheSQLGuru says:

    A lot of my clients have issues with Cowboy IT Operational Activity too. 😦


  2. way0utwest says:

    I’m sure. Not sure who’s worse sometimes.


  3. I find that my biggest hindrance is with management itself to good coding. I worked at a software vendor that made accounting software and in support we had scripts (text files with SQL code) that we used to fix various data issues that could not be fixed within the program. Ten years after I left I found out that many were still using my scripts not because I’m some kind of super SQL guru but because I took the time to do it right and that is not appreciated by management if anything its often discouraged. There is this belief that its best to do what you need to move forward and if there are any problems then we’ll cross that bridge when we get to it. No one wants to take the extra time to get it right to start with. As long as it works that’s all that matters. Its that kind of mindset that was the starting point for many software problems. A popular response from management when trying to justify taking the time is “that’ll never happen” and sure enough a few times it has. I understand that they are often under pressure from higher ups (assuming they aren’t at the top) but a sizable amount of our software code issues can be traced back to developers who were rushed and even discouraged from taking the time to do it right.


    • way0utwest says:

      Management certainly is an impediment or a supporter. I’ve seen these types of things before as well. Sometimes there isn’t enough priority on little things, sometimes they don’t make sense.

      The idea of not tackling things too early, makes some sense, but part of the idea of DevOps is we’re improving our skills, so that we have less of those things over time. If the same types of patterns or poor coding occur over and over, we’re failing at improving our process. If something doesn’t work and doesn’t get fixed, that’s a separate issue. There are choices and trade-offs to make, and it isn’t always worth the time to fix everything.


Comments are closed.