A Working Game Thrown Away And Built Again— Final Project Day 8

At the start of the project last week my team collectively agreed about the pace and work we would put in. Workload and hours people were putting in was something that had caused stress in previous group projects and it was something I wanted us to talk about openly.

In line with extreme programming practice we would aim for a focused 40 hours of work in the week, pairing or in our case working in threes wherever possible.

There was no pressure for people to stay later than normal, weekend work could happen but was not expected or mandatory. If we were to produce as good a product as we could focused effort was required.

I’d gotten quite used to the weekend work during the project so agreed to meet up with one of the team on Saturday.

We had a chat about best use of our time and as I wanted to confirm the product would work as expected I suggested we spike the rest of the project. It should only take an hour or two and then we’d be able to play and see if we had a game that was actually fun to play. If not we’d have to pivot and figure out what else needed to be implemented.

Spiking is writing code without tests. All the code written during spiking session should be thrown away after the experiment.

I was shocked at how quickly it all came together. The very careful test driven work we’d done all week meant it was really easy to add on the additional pieces required.

Where factories and services only two weeks ago were such a mystery now their purpose made sense and we were separating concerns like nobobies business.

In about an hour we had a functioning game. We had some other members of our cohort play it and it worked. We had made a fun thing.

Monday morning we had a discussion about what was created. We could either keep it and write tests for it or bin it and test drive it all.

It didn’t feel right to have put in so much effort in the previous week to test drive everything to just compromise now. So we kept working off where we were on Friday afternoon. It took an entire day to test drive it as we kept seeing opportunities to refactor. The product now is so much cleaner and modular then what was hacked together on Saturday.

We did have an interesting hour where we could not get one of our Karma tests to fail. Its still funny to watch karma evaluate

expect(true).toBeEqual.to(false)

and pass all tests.

We dug around the jasmine source documents with our coach to investigate.

Eventually we discovered we had our “done” in the wrong place in our test. Asynchronicity strikes again!

Another good day!

This is part of my daily blog series while I attend Makers Academy coding bootcamp. If you’d like to read more you can find them here.

Makers Academy Week11 Day1