As we want to deliver the best quality possible to our customers at the shortest possible timelines, we are always looking for ways to optimize and/or automate our workflow.
We’ve made some great steps in the past and plan to progress even further in the future. To do that I feel we best start looking at where we are now. I’ll do that by asking a very important question.
What would Joel do ?
For those of you who don’t know ‘the Joel test’, it’s a checklist created by Joel Spolsky that describes 12 points that will help in creating better & more stable code. Now this is by no way a final truth but it’s a nice starting point to validate the way we develop.
1. Do you use source control?
This is kind of a no-brainer, I’d hope there are no companies (nor individual developers for that matter) that would be comfortable developing without some sort of source control. Just to be sure that doesn’t include the ‘Yea but I backup my code to google drive once a week’ approach.
That being said, Yes, we use source control. In our development process we make heavy use of Microsoft Team Foundation Server (TFS), which supports two (internal) types of repository:
- Team Foundation Version Control (TFVC)
This is a proprietary centralized source control mechanism created by Microsoft and historically has been the default mechanism in TFS. https://www.visualstudio.com/en-us/docs/tfvc/overview - Git
A Distributed source control system, initially built by Linus Tarvalds in 2005. this system has been widely adopted by the open-source community. https://en.wikipedia.org/wiki/Git
Currently we use TFVC for most of our products, in the past we ran our own Subversion repository which we migrated to TFVC a few years back. As far as improvements go, what we are working on now is migrating our products to Git repositories. This due to the fact that we feel this allows for a more flexible development flow. I won’t go into much detail about this at this moment but I’ll try and elaborate on this some more in a future post.
2. Can you make a build in one step?
All our applications are build using TFS, TFS provides a very flexibly build system that has allowed us to fully build our applications and execute our asset pipeline. This results in build output (artifacts) that can be directly downloaded and distributed to our customers. We have put some effort in settings this all up, we feel that having these builds setup and really using them allows us to provide a stable experience to our customers. We also see some improvements ahead:
- Unit testing
We utilize unit testing in our code base, however the coverage of these tests leaves something to be desired. We are enforcing a stable coverage rate at this point (builds fail if the coverage declines) and are working hard on improving our rates where we can. - Code Quality
We recently started using SonarQube and integrating it into some of our builds. We were pleasantly surprised by the quality and detail of the information provided by this system and plan to integrate it in all of our builds overtime. We’re also looking into how we can integrate the data generated by SonarQube more actively into our development process. I’ll try and elaborate some more at a later time. - Integration/Regression Testing
The improvements mentioned above have a very low-level/code focus. Now it turns out that all this code is created with some functionality in mind. We are currently not performing any automated functional testing, which would definitely improve our ability to deliver new functionality in a speedy manner. This is therefore high on our wish list.
3. Do you make daily builds?
For our build we utilize Continuous Integration (CI), this means that whenever some code gets checked in a new build is triggered. Whenever a developer checks-in ‘broken’ code this will be noticed directly and grumpy faces will appear all around that said developer.
In this case we explicitly chose not to setup daily builds, we don’t do this as we maintain a lot of stale code, and prefer to not build all our applications when only some of them are in active development. Using the CI features that TFS provides gives us the direct feedback we want without our build server crunching the exact same code every night.
4. Do you have a bug database?
You might be starting to see a pattern here, but we use TFS for managing our workload. We maintain product backlogs and bug lists in there and try (emphasis on try) to mold those into proper sprints. We do tend to be a bit (to) flexible with the scope of our sprints, this due to the small team we have and changing priorities (which is not a good excuse, I know, but I’ll use it anyway).
5. Do you fix bugs before writing new code?
Not all the time, we have a list of low-priority bugs that we tend to give a bit too little attention most of the time. Of course if any high-priority bugs are found we try to fix them as soon as possible. In general I’d say we do fine here but a bit more discipline wouldn’t hurt I guess.
6. Do you have an up-to-date schedule?
Yes, this might seem a bit weird considering my bit about our sprints (see point 4), but that is more about the detail planning. We plan based on our Roadmap, this is our planning for a year+ ahead. While we near a milestone we tend to fill in the blanks and get to the detail planning. Now this might not sound very agile but it helps us give priority to the work we plan and gives some long term goals to work for.
7. Do you have a spec?
We document the functional scope of our project in Game Design Documents (GDD) our in-house tooling usually has some high-level architecture description but mostly evolves based on the requirements stated by the projects we build. Although these documents exist we are well aware of the fact that they aren’t nearly as extensive as they should be.
We have started with an online document portal that combines functional/architecture and technical documentation in an effort to allow for easy documentation. We are still looking to better integrate documentation into our workflow.
8. Do programmers have quiet working conditions?
I’ll put this down as a yes. To be honest our office if located right next to a children’s photographer, so we do have to put up with the occasional faint sound of ‘not so amused’ toddlers. But other than that we provide a quiet working area.
9. Do you use the best tools money can buy?
We most definitely think so! Utilizing the Microsoft tool-chain (Visual Studio/TFS/VS Code) and the advanced features this provides us gives us the best tools available. never the less we are always on the lookout for new tooling that can make our (development) lifes easier and try to fit them in our workflow.
10. Do you have testers?
No, even worst we are hiding behind nr. 5 of the ‘top 5 reasons you don’t have testers‘, we can’t afford them. To apply some nuance to that statement, we’re a small team and a dedicated tester would simply be too big of an investment. In general we make it a rule that all functionality checked in will be tested by someone from the team (who is not the one checking it in). This forces a fresh set of eyes to look at what was build and also keeps everyone up-to-speed on the changes being build.
For the aforementioned reasons we like this setup and currently are not planning on hiring a dedicated tester.
11. Do new candidates write code during their interview?
Yes, we ask candidates to solve some coding ‘challenges’ usually before they come to the interview. This shows the applicants level of (game development) knowledge, gives us an idea of the way an applicant would approach a problem and most importantly it gives us something to talk about during the interview (we just enjoy talking about code).
12. Do you do hallway usability testing?
Nope, not a very good excuse but we don’t have a hallway…
But seriously we currently don’t do hallway usability testing. Part of this has to do with our size but we should do this in one way or another. I’m open to suggestions about how we’ll fit this in our workflow. 🙂
In conclusion
We are definitely not there yet, however it is our goal to eventually check the entire list. As you may have noticed a added some color coding to each point in the list to to give an indication as to how far along we are 🙂
For now we are quite happy about where we are. Improving our work process is a constant point of attention and we plan to update you guys as we get closer to being ‘joel approved’ 🙂
Any tips/tricks or any other forms of advice to improve the way we work, we are always interested to hear from you.