This is the second post in my work based learning blog series. If you need some context, or some of the things just aren't making sense, read the previous entry. The previous blog entry was full of verbose analysis and self-reflection. It turns out that the blogs aren't marked at all, and are merely supposed to provide a well of documented experiences to draw from so I can write a report. As such, this blog is going to be a little shorter.

What I did this week

Day 1

The colleague with whom I had arranged to car share had had a family emergency. This meant I had to get the train again, but I still made it to work early.

My student colleague had arrived before me, and it was starting to become apparent that the first library we were tasked with trying out (GoJS) had its fair share of shortcomings. Most of the simpler features such as scaling, rotating, drag creation, etc came out-of-the-box. However, when we tried to combine the features into a usable proof of concept, they tended to conflict in some way. The amount of additional code we were writing for workarounds evidenced a deeper issue with this proposed solution: it did too much. My feeling was that one of the senior developers had all but officially chosen GoJS to replace the unmaintainable code as the tool's site exhibits some admittedly impressive samples. This presented a problem: how do we persuade him that the reason he favours the framework is the reason for it not working?

Our team had a short Skype meeting to catch up on the previous week's events. In the meeting, I suggested to our seniors that we should start wrapping up the investigation of GoJS and move on to the next framework. I made sure not to push the issue too hard, and instead tried to facilitate the senior developer's inquiry into the matter. I explained that we were having to make trade-offs frequently when combining the POCs, and that the style GoJS requires a developer to write in made having our cake and eating it a Sisyphean task.

Fortunately, by the end of the meeting, everyone was in agreement. We would spend the next couple of days wrapping up the exploration of this tool in preparation to move onto the next. For the rest of the day, we filled in the feature comparison matrix by examining our POCs and the samples on the GoJS website in order to provide evidence for our conclusion that we would present the next day.

Day 2

The time of the presentation approached. Despite the fairly extensive documentation we had prepared, the affair was a casual one. We worked our way down the table of required features and explained our implementation. As the senior developer asked us questions about our POCs, I made sure to only answer the questions related specifically to the features I worked on most. I encouraged my course mate to expand on his features, and this time, the conversation seemed better shared between all parties.

Thankfully, very little actual persuasion was needed, as our evidence seemed to speak for itself. We were told that the next week would have us working with a different framework.