In March I received an email from my old University (The University of York) out of the blue asking if I would be willing to accept a nomination for the Duke of York Young Entrepreneur Award. I was really surprised to be chosen, especially as I was now a graduate!
Receiving my award from the Duke of York
The ceremony itself was in Huddersfield and was really exciting: His Royal Highness took an incredible interest in the businesses of all the winners and it was great to hear what others were up to.
Since I was in the Yorkshire area, I took the opportunity to visit my old University and meet with some of the Entrepreneurs currently working with the Enterprise Department which was great fun.
One of the 2nd Year Computer Science modules at York is the Software Engineering Project (SEPR). In this module, you work with a team of ~6 randomly allocated peers on a project to simulate an industry environment. Since I’ve had a good amount of industry experience I thought I’d write something about the module and how it simulates industry.
First, let’s talk about SEPR – what is it? The idea is that it simulates your team working within a company to produce a product. Different members of the module leaders act as the ‘customer’, module support team and ‘managers’ (i.e. for if you’re having major problems in your team). The customer gives all the teams a specification document of the product he wants to be produced, and this simulates industry in that the document is vague at points and has gaping holes (where the customer doesn’t know what he wants).
A number of things are been testing in SEPR:
how you work with a team (i.e. if you’re a team player),
how you work collaboratively (i.e. are you emailing code or using collaboration tools like Git),
the structure of your product (i.e. is your product expandable – is it easier to add more classes to enable more features?),
the quality of your code,
how you market it (at two stages in the course you are required to take up another teams code and to try and convince other teams to take up your code).
For our year, the project specification was to create an Air Traffic Control game, where planes would come onto the screen, with a route marked as a series of way points. The players job was to prevent collisions. In the revised specification for the final assessment, we were required to implement a multiplayer game mode.
Our First Game – Day Flying Game – Ugly right?!
Our Second Game – Controller Concern Mk. 2 – getting better…
So, how well does this simulate industry? In my opinion, it does a pretty good job. The structure of the SEPR module means that you have a wide variety of personalities that you have to work with, which can of course be difficult at times – some people have only worked in isolated environments in the past, but it works out well and it’s rewarding when you work out how to work together. Specifically with my team, I think it’s fair to say that a couple of members would not be friendly with each other outside of the module, but it didn’t take too long for everyone to learn to work together, and that’s a very valuable skill.
Collaboration tools are of course a big thing in industry – it’s not possible to develop just by sending code by email and on flash drive to people, although up until the SEPR module I’d say a large proportion of students in my course had been surviving that way. A team of 6 is big enough that you need to use these tools, which is great as they’re the same (or very similar) tools as those used in industry.
It’s obvious, but it needs mentioning – in industry you’ve got to write very maintainable code – code that will remain within a product for 10+ years. Since the module is marked on this (and UML diagrams should be provided in the written reports), it represents industry well, although perhaps with less consequences if you do screw up!
The only imperfection in the module that I was aware of was how teams are created and managed. Teams were selected almost entirely randomly by the SEPR module leaders, under the justification that “in industry, you can’t choose who you work with”. That means that each team was made up of people with vastly varying skill levels – some teams had multiple people in them who couldn’t program at-all (which, in my opinion, is not good to say they are passed their first year of study in Computer Science). But – in industry, you do work with people of a similar skill level – that’s why companies have interviews, to ensure that their new employees meet the level of the current employees. And poorer quality companies don’t end up with a random group of 3 geniuses (or at least, they normally don’t), because those 3 people know they could go and get a better-paying job at a better company. So I don’t think this was done well in the SEPR module – teams should have been made up of groups of students of similar ability, so that good students got good marks and vice versa, rather than students of extreme (either poor or great) ability levels having a great influence on the mark of the overall team.
So, to conclude, other than with team selection, I think the SEPR module does a great job of simulating industry – the right things are taken into account (team skills, working collaboratively, and code quality), and the structure of the module in terms of lecturer leadership accurately simulates the various levels of management in a company.
To take a look at and try the three games we created, check out the SEPR section of my projects page.
I was lucky enough to be asked to come and demonstrate Google Glass at Venturefest Yorkshire 2014 last week month (time ran away!) (representing myself, a Glass developer). Venturefest is a free one-day event showcasing the latest technologies and businesses, and it’s very popular with entrepreneurs.
Venturefest ID
As Glass hasn’t become publicly available yet, this was an exciting opportunity to demonstrate Glass to some of the UK’s most innovative and creative minds, many of whom haven’t yet had the chance to experiment with any wearable technology in the past. My goal was to demonstrate it’s potential and to spark an interest or idea that may lead them to start developing for wearable devices – development which just isn’t mainstream in the UK yet.
So, bright and early on the 14th of March, I headed out to the York Racecourse where the event was been held and setup my demo – simply Glass, a power cable to re-charge it at every possible opportunity and a laptop showing videos of Glass been used from the Glass YouTube channel. From 9AM through 1PM, I was constantly busy – it was definitely a very popular device. So, what was the feedback?
The first thing I noticed was that nobody seemed to know how to use it! This is different to the US where someone asks you to try it and with the smallest of hints they’re away and navigating through features. Perhaps this is down to the additional media coverage it’s had in the US compared to the UK, but I was still surprised at how few people had investigated it in the year it’s been about, bearing in mind it seems to be the future.
The general feedback was that people were extremely impressed with Glass – specifically, a number of people commented on how unobtrusive it was when it was switched off (you can see right through it) and on how incredible Google Now on Glass was – two distinctive questions that it correctly answered were “What’s the capacity of the Riverside Stadium?” and “What is the nickname of the Bank of England?”.
One specific piece of feedback I did keep getting was that “It would be really useful as an Augmented Reality device for my …”, which is an area that, up until now, I haven’t thought hugely about. It does seem obvious though, as it’s a much more natural device for augmenting your vision than, for example, your phone, which you must constantly hold up in-front of your face.
All in all, I think it went well and that people enjoyed the experience. Fingers crossed that I managed to persuade a few more people that wearable technology and Google Glass really are a viable future.
