So How Bad is Cowboy Coding, Really?
Actually, it's pretty bad. It's usually because of some Cowboy Coder that lead our clients to us in the first place, whether that coder was a dev team member or the president of the company. Thanks to AI builders in the hands of entrepreneurs and the self-confidence of programmers, it's kinda 50/50 at this point.
That being said, we recently had a cowboy coding scenario and honestly, it worked out beautifully.
So how bad is cowboy coding? Well, if you do it with some pre-planning, it can kind of tame the wild west of computer code. Here's how.
Have You Been Cowboy Coding and Not Known It?
First, we should really define Cowboy Coding. We'll go with the Wikipedia definition of "software development where programmers have autonomy over the development process. This includes control of the projects schedule, language, algorithms, tools frameworks, and coding style" (yes, we added an Oxford comma in there where there originally wasn't one. Anyone who cares can pry my stance on it out of my cold, dead hands).
Wikipedia also really nails the disadvantages, as we've encountered most of them as well: lack of release structure, uncertain design requirements, and (thanks to AI) because of inexperienced "developers", there's often incompleteness.
The convenient thing is, though, if you're an experienced developer like our team in the Denver metro area, you know these issues are going to spring up, so we have a methodology for you to use.
How to Cowboy Code Like a Pro
Plenty of cowboy coding happens on new, experimental software. In our line of work, we see it running rampant on existing, live software. If you have been tempted to tweak, add features, or completely rework your live software (or suffered the consequences of doing it), this is for you.
Create a new branch. We insist all clients have GitHub, the repository is too valuable not to have. Your live application is the main branch, but we're going to set up a staging environment in your hosting platform and create a cowboy code branch from your live main as it exists now, and we're going to go wild here.
Be on-premise. Seriously, the only time to really be completely unstructured, experimental, and maintain total control over this enhancement or feature add, you might as well be right where the action is. Look over shoulders, ask questions, experiment with new and better ways to do this. You're the developer (or AI-builder handler) and know the language to get the result. Other people aren't developers and don't understand how to ask for what they actually want. Looking over shoulders usually eliminates lost-in-translation implied meaning. Most importantly: please schedule this when the action is slow. Making improvements on the fly during peak business hours is not the time to do it. Pick the slower hours and/or slow season and schedule it for then. You still want to see real-life software UX, so don't schedule it when business hours are dead, just slow.
Get Real-Time Feedback. You can do this because you're on-site watching the process in real time, or you're sitting next to whoever is running this software in the office. When there's a lull, ask the actual user or multiple users to try out the staging environment to try the change you made. Get live feedback. Does it work? Push it to main! Let them use it now! You shouldn't really have a worst case scenario because you're coding on the freshest branch of the live main, but just in case there is a worst case scenario once you commit it to main, you can just roll it back. You can do that thanks to GitHub.
Stay There, Watch, and Tweak. This is the important thing: you can't just watch for 45 minutes, push out cowboy code changes, and expect the best. You need to stick around and watch them use it. Listen for edge cases. Talk to them in the slow parts about what a better working solution looks like. Tweak, test, push live. Repeat. We will spend multiple hours to almost the entire work day on-site watching, interviewing, pushing changes, watching, asking for feedback, pushing changes again. For large on-premise projects, we'll spend multiple days on-site. But the nice thing about this? Once the software UX is dialed in, everyone fawns over the developer. When the developer spend hours and days improving the software to actual user delight, the developer becomes the greatest thing since sliced bread.
Double Check Your Work. Once you're no longer using the software users time, go back to your desk and check your work. Scan for security issues or holes, make sure the code is clean, documentation is finalized, etc. Whatever best practices you didn't do in the moment because you were just focused on a better user experience, do that now.
And that's it! That's how you prevent catastrophe while cowboy coding. Is this still cowboy coding if you're being this cautious? Of course it's still cowboy coding! Cowboys are still cowboys even when they're playing it safe: they're not going to be good cowboys with a broken leg; you're not going to be a good developer if the company's operations completely halts because you were working on the main line.
Happy Trails!
Good luck out there, buckeroo. If you haven't recovered fully from your last cowboy coding rodeo, reach out to us on our contact page and schedule a Discovery Call. If we can steer you back to the beaten path in 15 minutes, we're going to do that. If you need more ranch-hands for your fix, we're available for that too.