Programming Workflow

Another thing we wanted to consider before starting coding was creating a proper programming workflow, so that our code is easy for everyone to work on. Providing a workflow methodology will also hopefully mean that if something breaks in our code we won’t find it too hard to fix, due to it being well version controlled and commented.

One way that software companies can control their workflow is by using the Joel test, created by the CEO of stack exchange. Although some of it is not relevant to our project, such as requiring candidates to take a coding test before being hired, some of the principles could come in very useful for our project.

The Joel Test

  1. Do you use source control?
  2. Can you make a build in one step?
  3. Do you make daily builds?
  4. Do you have a bug database?
  5. Do you fix bugs before writing new code?
  6. Do you have an up-to-date schedule?
  7. Do you have a spec?
  8. Do programmers have quiet working conditions?
  9. Do you use the best tools money can buy?
  10. Do you have testers?
  11. Do new candidates write code during their interview?
  12. Do you do hallway usability testing?

The Joel Test, (Joelonsoftware.com, 2000)

For the first item, we will use Git and a private BitBucket repository in order to source control our project. This means is something breaks, we can always revert back to the last version that worked.

Building in as little steps as possible means that coders can quickly test the effects of their code, thankfully XCode has an inbuilt emulator which makes building the code almost instant.

As we code, we will build after making any changes to make sure the code still works. If it does we will then push it to the BitBucket repository so that we have a working version saved.

We will keep a bug log that is bundled with the project and also comment in any bugs in the code itself.

I will create a Gantt sheet in order to keep the project running on time.

We have already created a spec here with our game design document, and a coding spec here.

Unfortunately I cannot do much to control the working conditions as I must work at university due to XCode being only available on Mac computers. (I wrote more about this here.) Also the next item is beyond my control.

A hallway usability test is where you grab the next person that passes by in the hallway and force them to try to use the code you just wrote. If you do this to five people, you will learn 95% of what there is to learn about usability problems in your code.

The Joel Test, (Joelonsoftware.com, 2000)

The last two points are related to testing our game before it is published. Hopefully if we are on schedule we can have time to test our game with a variety of people before it is completed. It would also be good if we could test our code with the target age group, however this might be quite hard to get permission for in the time frame.

Joelonsoftware.com, 2000. The Joel Test: 12 Steps to Better Code – Joel on Software. [online] Available from: http://www.joelonsoftware.com/articles/fog0000000043.html [Accessed 30 March 2015].