An honest glimpse at the codebase of the popular Words With Friends games offered up a key instruction to managers and developers at GDC today.
"Don't be afraid to step back and pivot."
Principal engineer at `Zynga With Friends (studio formerly known as Newtoy) said that while successive iteration on the game meant a sprawling codebase ("bandaids on bandaids on bandaids"), he had learned how to drive team morale via coding that he shared with other attendees.
The biggest takeaway was on fostering the ability to question and edit amongst your coders.
"Don't be afraid to step back and pivot. In my experience people who are willing to objectively evaluate where you are and where you are going is an incredibly powerful skill," he said.
"And it's a skill you can build and cultivate inside your employees."
He explained that developers and managers should encourage each other to "look at your game, your team, your development process, and ask 'is this the right path to go down?'"
It might sounds like common sense, but he said that being willing to revamp and change ideas means to can "continually foster productivity and efficiency".
But you shouldn't use that as an excuse to have "clean slate rewrites" and embrace a more flexible - perhaps even chaotic - way of programming.
By example, Thakkar offered a very honest insight int the once chaotic codebase under Words With Friends.
With four 'With Friends' game brands now (Hanging, Words, Scramble and Chess), that means 15 applications across Facebook, iOS and Android which has created "kind of a nightmare" as the developers grew and grew their game.
The core Words iOS game was no different, and had a "very messy" code.
When it came to porting the game to Android, the coder responsible for the build had to take said messy codebase and port it, line by line to java.
Only then was the team able to understand what could and couldn't be kept or killed.
"Building up code debt is ok," he said as long as 'it could be paid back later' - and through the life of the games the codebase has been refined and perfected.
But to start with, developers should be caring about their project, not their code.
He talked of three kinds of code: functional code, beautiful code, and maintainable code.
"Beautiful code? That's not that important."
Instead, developers should look at creating functional code which they make maintainable before thinking about it being beautiful.
"If you ship a game with beautiful code you fail, if you ship a beautiful product you succeed."