I’ve spent a little over a month checking out game developers on twitch and similar, getting a feel for what goes into making a game. I wanted to know what differences there are between game developers and the rest of us mere mortals. More importantly, I wanted to know why differences exist.

This road of discovery has provided many insights and all too many disappointments. I want to quantify early on; my experience in development has been in a broad variety of industries, but has never before included gaming. As a follow-up to this article, I intend to do some twitch streaming over the coming weeks with a good friend of mine, applying clean coding and best practices whilst we take on a game or two. After all, how critical can I be without having walked a mile in their shoes!

First Thoughts

Pretty shocking. And I mean in a ‘you make my brain hurt’ kind of way.

Admittedly, my perspective on the gaming industry will have been somewhat tainted by the fact I was only looking at streamers. I suspect some would argue that only younger and less experienced developers would expose themselves and their code publicly. Not to mention the intellectual property issues a more established game developer might face; so it’s perhaps fairer to say that my studies have more directed toward indie game development? I’d definitely be keen to hear from more experienced senior (really, senior) game developers if they do (or do not) believe this to be the case.

Regardless, I was participant and audience to a good sampling of development experience through these streams. Some clearly new to C#, whilst others boasting more than 25 years in the field.

Not a single developer of the more than 100 I watched, used anything even resembling clean code. I didn’t, throughout the entire period, see a single automated test, unit or otherwise!

Easy Prey

As a senior developer, I believe it falls upon me to try and help these young padawans. It’s my responsibility to assist, teach, collaborate, review, and supervise others (as it should be of every developer!).

It became quickly evident that this was no small task. I put aside more time than I expected, and even enlisted a few friends and colleagues to assist me in this uphill battle. I found my company’s most junior developers were considerably more senior than any game dev we came across, so we weren’t short on hands.

Finding the worst game devs became a sport - my dinner once or twice interrupted by texts from friends with twitch url’s; a call to arms of sorts. However, these messages and rally cries seemed to be as frequent as streamers going live. In fact, at peak, I have no doubt they were exactly that.

As a keen gamer over the years, I’ve been receipt to my fair share of buggy games, and never understood why bug fixes and new features would be released so slowly, so unreliably, and with so many new bugs.

It was very quickly becoming very clear.

Excuses

I often find, and perhaps through fault of my own, that preaching the ways of clean coding can be akin devout religious followers preaching to the most athiest among us. It simply does not go down well.

In the worst of cases I was timed out from the streamers’ chat, their faithful followers spurging incoherent abuse whilst the streamer took strong defensive stances. On the opposite end of the spectrum, there were those that I assisted, providing reference material and knowledge as best I could through the medium that is twitch chat.

The vast majority of streamers sat in the middle ground. That dirty grey area that so many developers across all industries seem to be in. They’re aware of clean coding on some level, but have a broad array of excuses for not employing it. My favourite of which had to be “but I just need to push this software out the door”… The ineffable excuse that is time constraints.

All developers have to push software out the door, even if that door is internal to their company. The difference is, I want it out the door sooner, with less bugs, and less chance of it coming back in the door!

Myths and Misconceptions

Clean code takes longer.

I’ve seen Uncle Bob himself struggle against this particular line, so was not surprised to find myself having such difficulty. A common misconception is that clean code takes longer. I disagree whole heartedly. And I don’t just mean that middle ground people so often agree upon that in the long run clean code breaks even.

Just, no. Writing code cleanly, utilising OOP design patterns, following SOLID principles, employing Test-Driven-Design throughout an Agile workflow does not take longer than writing code normally. These things take no extra time once you are comfortable with them.

Saying “clean code takes longer” is like telling me that writing code with a DVORAK keyboard is slower. Well, of course it will take me longer whilst I become accustomed to it. But once I know it… as soon as clean code flows from my finger tips, it no longer hinders my progress or takes longer. The very clever people that came up with these ideas, did so because working this way is better!

Yes, it’s an investment of time learning new ways, but it’s your responsibility to do so. You can thank yourself later!

Refactoring

For me, this is the greatest benefit bar none. If there was no such a thing as clean code I would like to think I would somehow find a way to ensure my code was high quality. It would work, it would have as few bugs as possible, it would take as little time as necessary to complete and run, and it would be very readable. My pride in my work would allow no less.

But even if I ignore how much easier following good practices makes all that, the time lost on refactoring would be immense.

I call it “the Boy Scout rule”: Always check in a module cleaner than when you checked it out. Always make some random act of kindness to the code whenever you see it

Uncle Bob - The Clean Coder: A Code of Conduct for Professional Programmers

Every time a refactor causes a test to fail, I high-five myself. That failing test is a feeling of achievement and joy. It is a behavioural abnormality that potentially, I would otherwise have shipped.

Every time I enhance my software or adapt the behaviour by simply switching out an existing component, I pat myself on the back. I’ve done it right, and I’m being rewarded for having done so.

Every time my Continuous Integration build fails, I pour myself a beer…

Every developer refactors code. Why take such a risk? Why make it any harder?

Professionalism

This is where we really hit the nail on the head and determine the men from the boys. How long will it take to finish that piece of work?

Does your response take into account the time it takes to cleanly code the work, or does it depend?

If the latter, you’re being unprofessional.

Estimates must account for the time it takes to TDD, to refactor parts of the legcy code base you’ll be working, the time it takes to spike some code to better understand a technology, the time it takes to peer program, collaborate and share knowledge. These are not optional extras that you can cast aside when the going gets tough or when the project manager is getting a bit loud.

Imagine a surgeon working in such an unprofessional manner?

“I’m afraid the big boss man is putting us under a lot of pressure; we’ve got a load of operations we need to get through this sprint to meet their deadlines, so we’ve had to fix your broken arm by amputating it. It’s much quicker, it shouldn’t bother you that greatly, and I’m sure we can revisit it later on when we get more time.”

Show some balls, stick to your principles, and be a professional!

We need to become a self-regulating and self-policing profession. The stakes are simply too high to allow software to remain in the current ad-hoc limbo of hackers, heroics, and hermits.

Uncle Bob’s - The Letter