Developing “Code Smell”: How To Gauge Programming Quality Without Knowing Anything About Programming

Posted: October 20th, 2018 under Game Development, Opinion, Presentation.


If anyone is interested in having more successful projects, this is a great talk for you. First presented at M+Dev 2018.

  • My Current title is Game Engineering Team Lead at Filament Games.
  • I’ve worked at a lot of places, but what is particularly important for this talk is that I have made a lot of stuff.
  • I’ve had a lot of work diversity, but in particular I have worked on a lot of small teams, and have been around a lot of other small teams.
  • Also, particularly in my experience at Filament Games, I need to facilitate a lot of conversations with clients, staff, and visitors about programming issues and make problems approachable.
  • “Code Smell” is a specific “Project Sense” where you can quickly gauge the health of a project.
  • It is all about how to have more successful projects.
  • This talk started as professional development for staff at Filament games
  • There is a great scene in the Disney Movie “Wreck It Ralph” that captures it pretty well. – Except that it is way too pretty and it is also copyrighted.
  • Most people understand that a programmer creates distinct objects out of data that represent things. Like a character has a number that represents health, and maybe another one for money. Then there are also rules written on how and when those properties can be modified.
  • What most people miss is that their is a big part of programming that is wiring things together, and during development connections are frequently changing.
    Furthermore, when your code runs, data is moving through it, we literally refer to it as flow of control, we often need to trace paths through it.
  • I specifically chose this picture with wires of the same color because this is exactly what it feels like to try to read poorly labeled code.
  • There are things called UML diagrams
  • Can anyone read this? Does anyone know what this is?
  • This is the schematic for a nuclear substation
  • Does anyone here feel like they can construct a nuclear substation with this guide?
  • Does any else feel like their is a pretty big gap between reading this and knowing what the final product will look like?
  • Software UML diagrams don’t look that different
  • UML diagrams have similar flaws that design documents have, they are perpetually out of date.
  • I would describe them as almost worthless.
  • I’ve been asked to make them, no one has ever asked me a follow up question.
  • Any attempt I have seen at visual programming quickly get overwhelming
  • But again it reinforces the idea of data flowing through a system, these visual languages give you a way to “see the wires”
  • Anyone want to venture a guess at what this does?
  • It sorts a list.
  • This isn’t necessarily a list of junior programmer problems, some programmers never seem to grow out of these.
  • This isn’t a complete list, these are just the ones I find to be most common

  • My favorite metaphor for game development is building a house. It isn’t perfect but it communicates to clients what the experience of game development is like: there is a block of time at the beginning, where to an outside observer, not much is happening as we are laying the foundation. Then there appears to be a burst of productivity where we frame in the house (alpha). Then their is a long steady tail of polish and adding systems.
  • Every week you should be reviewing the blueprint, the budget, and the schedule – as we have established though, even if you have a blueprint you can’t read it.
  • This guy is actually kind of a jerk – but he can tell you everything you need to know about project management in under 10 minutes.
  • Would anyone hear go about building a house and say “Let’s worry about the second story when we get there”? Or “Go ahead and lay the foundation while we figure out the floor plan”?
  • Leaving design phase without enough of a plan creates constantly evolving parts of code.
  • It is natural to try and rework something you already have instead of throwing it out and starting over (sunk costs), particularly if there is pressure to continue to keep the feature in budget.
  • Even though organic code is the symptom of process problem it is still the programmer’s fault for not demanding designs and requirements, forcing decisions to be made.
  • If people commit to something then change their mind at a later date, you still have the same problem – but at least you can charge money or ask for the delivery date to change.
  • Sometime this can be mitigated by asking the programmer to build a system with a lot of flexibility / variance
  • Again, this comes down to process, strong programmers will push to order features from most risk to least risk in their discipline.
  • There is a lot of competition for order of features, weaker programmers can let the team or client decide what is most important.
  • They let the project happen to them, it can also happen frequently when a new person joins a team.
  • A really giving generous person in a programmer role might help and support everyone else on the team delaying tech only responsibilities.
  • A programmer that is slower than people in other roles is just like the generous programmer, all their time goes to unblocking teammates.
  • A programmer could be scared or nervous about a really difficult challenge and avoid it.
  • Even if you can’t observe code directly, you can still observe its effects.
  • How would you rank a team programmers if you couldn’t read code?
  • You would most likely look at other production indicators like velocity, features, and defects
  • If you asked a programmer what was the best code they wrote on a project, what do you think they would say?
  • Story about UI development at NetDevil, the project was very large, it never would have gotten done if we had to revisit past work.
  • Whenever there was a defect, I had to think about “How can I fix this so that it will NEVER happen again?”
  • The code I was most proud of was the code that went a year, or a year and a half without needing to be edited, despite all the new features.
  • Look change on a project is inevitable, no programmer is ever going to have constant velocity, or estimate perfectly
  • Some maintenance can actually be desirable – one example are QA and Design tools that become part of the “vertical slice” of new features
  • However, most of the time the goal is write zero maintenance features
  • Easy question to ask when starting a project is if they have ever built something this big / complicated before
  • While no one is going to have constant velocity, Inexperienced programmers can literally reach a point where forward progress halts
  • It is entirely possible to write code that you cannot debug – “code is twice as hard to read as it is to write”, think about the mess of wires earlier in the presentation
  • Or they will just have too many bugs affecting new work
  • Inventory system example: items, consumables, item stacks, bound items, items part of item sets – even if we do not implement the full spec all at once we need to know where we are headed.
  • If this is happening on your project, you might need to pause new work and let the programmer catch up or re-write a feature, otherwise it is going to keep taxing your time.
  • This concept is pretty easy, the red here represents the project requirements.
  • It is a range because there are always going to be some options built into the system: health, size of things, speed of things, etc.
  • Less experience developers will too rigidly adhere to the spec – if the spec changes they will have to go back and update things.
  • Veterans know that the spec is a lie and it is going to change.
  • The green funnel represents what a more experienced programmer will code given the red spec – so long as the cost was marginal.
  • A really good programmer will give you a file so someone else can fiddle with the options without bothering them

My defensive programming post.

  • As a programmer we get to decide what failure looks like, there are other options besides just letting your game crash.
  • I am of the philosophy that your code should almost never crash – It prevents testing / blocks other developers / stacks of crashes
  • “I was three hours into a game and it crashed” – good luck reproducing that defect.
  • The cost to fix a defect increases the longer it goes unnoticed
  • How someone treats QA – I challenge you to find a flaw, I bet you can’t break this. They shouldn’t be checking your work.
  • My code runs a self diagnostic when it starts up and while it is running- as long as I write the tests correctly it is going to report problems preventing mistakes and having to diagnose issues.
  • The tell tale sign of an encapsulation problem is work being done on one part of the game, and something seemingly unrelated breaks.
  • It might not always be feature work, it could be trying to fix one defect creates or re-opens a defect in another place.
  • What is happening in code is that there isn’t clear separation of responsibility. Two or more things are tightly coupled together, or multiple systems are competing for control over the same set of objects.
  • Code is less reusable and therefore less valuable.
  • It will frequently stem from writing an interaction between two different kinds of objects, or cyclic relationships like radio buttons
  • Writing friendly fire code example
  • If you find yourself in what feels like one of these situations start asking questions, request more information, and get someone with expertise involved.

No Comments »

No comments yet.

RSS feed for comments on this post. TrackBack URL

Leave a comment