Which Computer Science Option Should I choose?

After my First Year lecture today someone asked me an interesting question: "Which Computer Science option should I choose for next year?". Our course is structured so that you can choose your specialism (Computer Science, Software Development, Game Development, Information Systems or Computer Systems Engineering) at the end of year one. I think (although I may be wrong) that the person asking the question was primarily concerned about the best option to choose from an employ-ability point of view.

My answer was that you should pick the one you are most interested in. When you go for a job it is very likely that your prospective employer will not necessarily be looking for someone with a particular specialism. They will just be looking for someone who is keen on the field of Computer Science and shows the prospect of being useful.

To me this means a candidate who has done lots of things that aren't on the syllabus and can talk about the things that they have made "just for the fun of it" as well as the good grades they got on their set coursework.

So, do the thing you enjoy, and do stuff that you haven't been told to do, and don't worry quite so much about being a good fit with what you think the employers might want. 

Make Your Documents Work for You

I've spent a chunk of today performing Seed exit vivas. This is where students on our industrial placement module have to come along and explain why they should get 5 out of 5 for Project Management. Or whatnot. We discuss things for 45 minutes or so and finally agree on figures for each marking category. Sometimes the figure goes down, but in a surprising number of cases we end up delivering the happy news that we think that they have undervalued their work. Which is nice.

One thing I like to do is point at pages that have been supplied as part of the thick folder of documents and ask "What's that for?". This can be quite illuminating. For example:

"What's that for?"
"It's the Risk Analysis."
"OK, where did it come from?"
"Well, at the start of the project we wrote down all the risks we could think of, and that's the result."
"Did you ever look at it again?"
"No. Should we?"

.. at which point the conversation goes downhill a little bit. Risks should be identified and then tracked over the project. At regular intervals the document should have been produced and checked over to make sure that nothing has changed, and that none of the risks were becoming critical. 

If you are going to take the trouble to make a document that is part of your development then you are making an investment in your time. It is important that the investment pays off. Documents should "earn their keep".

The Risk Analysis document should be checked and updated at regular intervals to make sure that risks are managed. Minutes of meetings should record who was there, what was said, give people actions and check on actions from earlier meetings. Specifications should be signed off. Tests documents should be acted on and then the results of the tests recorded and used to drive future development. I could go on (and in fact I did - quite a bit). 

I got the feeling that some of the documents were shoved in "because we thought we had to write them". I also got the feeling that some folk thought that writing all this was a distraction from the proper job, which was creating the solution for the customer. However, this is very, very, important stuff. It can make the difference between success and failure in a project. And doing it right will definitely get you higher grades....

Of Garbage Man and Banjos

AlienBanjoAttackShot.PNG

This year the first year students can create a game as part of their programming coursework. The game is "Alien Banjo Attack" and above you can see a screenshot of my demo version. At the top are various different types of evil banjo and your mission is to defend the earth using nothing more than your accordion which will shoot notes of music to destroy the incoming swarm.  If the banjos reach the bottom of the screen you lose the game. If you crash into a banjo you lose a life. Space Invaders with a banjo feel. What's not to love?

I want there to be loads of objects (notes, banjos etc) on the screen at the same time, which means a lot of instances of the various classes that represent the game objects. There has been some discussion about the best way to handle this, as banjos are destroyed and new ones appear.

I reckon the best way to do this is to make a banjo stateful. The banjo will contain a flag to represent whether or not it is involved in the game. If a banjo is destroyed this flag set to indicate that it is dead and the banjo plays no further part in the gameplay. When we need a new banjo we just have to find one which is marked as dead and "resurrect" it by moving the banjo to a new position and then changing the flag to bring it back to life. 

You might think that creating new instances of banjos to replace discarded ones would be another way to achieve this behaviour but I don't like that at all. If we start creating and destroying objects this will make work for the Garbage Collector who will have to come in and tidy up memory every now and then which might slow things down a bit. 

Another way to reuse objects would be to keep a list of "dead" banjos. Each time a banjo is killed we move it out of the "active" list into the list of dead ones. That way, if we need a new banjo we just have to look in the list. This is a bit more complicated than just searching for a banjo that can be resurrected, but it does have the advantage that the game never wastes time working through "dead" display objects, as these are no longer in the active list.  Many operating systems use this technique in what is called a "thread pool" where previously used threads are kept ready for use by processes that might need them.

Phil and Stuart talk iPlayer Transcoding

Phil Cluff and Stuart Hicks getting ready for the off

Phil Cluff and Stuart Hicks getting ready for the off

We love it when ex-students come back to the department to tell us what they've been up to. Phil Cluff graduated a few years ago and Stuart Hicks a couple of years after that. Since graduation they've both been working for the BBC on the iPlayer team.

If your'e not from the UK you might not appreciate just how wonderful BBC iPlayer is. It lets you consume BBC TV output on any device, in any place. All the output of the BBC channels, plus the content from BBC local TV, is made available shortly after broadcast so you really don't have to worry about missing things. The programmes are available for a number of days after transmission and they are also made available for download. It's awesome. Phil and Stuart  told us that 3% of the consumption of BBC output is now via iPlayer and it is growing rapidly. There have been around 28 Million downloads of the iPlayer apps across the various platforms,  they get around 10 million requests a day and release around 700 hours of new content a week.  Amazing stuff. 

Of course, getting all that content onto the internet is a tricky job. The original content has got to be converted into the different video formats and sizes that are consumed by the users, and this must happen as soon after broadcast as possible. Nobody wants to have to wait until tomorrow to see today's news. There are huge peaks and troughs in demand and this makes it tricky to manage the computing resource that you need for the task.

A little while back the BBC decided to move their transcoding (as this is called) activities into the cloud. Phil and Stuart described the cloud as "A collection of services that someone else runs for you, which lets you not care about hardware". Which is just what the BBC needed. So they put together a project to build a cloud based "Video Factory" from scratch in 18 months. And they did it. 

Large computing projects are notable for failing or being expensively late. The Video Factory was neither of these things. Phil put this down to the way the design was based on a number of small components, each of which performs one step in the process of getting the video into your iPhone or whatever. The workflow of the video data through the system is managed as a series of messages that are passed from one component to each other. Components take messages out of their input queue, perform their part of the process on the message and pass it on to the next component.  If things get busy and queues start to fill up the system can "spin up" extra processing resource in the form of further servers in the cloud which can run components to work on the extra elements. 

And because each component has very well defined inputs and outputs this makes testing much easier. Phil and Stuart talked about Behaviour Driven Development, which is where you express what you want to achieve in terms of business outcomes. They used a language called Cucumber which lets you express your requirements in a really easy to understand way, and will also produce a whole framework of tests you can use to prove the solution. This is very, very interesting stuff.

It was great to see Phil and Stuart again. It looks like they are doing very well. It was also really nice to hear them echo a lot of the things that we tell our students during the course.  They had some very useful things to say about the craft of development. You can find the slide deck of their presentation here. I strongly advise you to take a look at the last few slides, there are some lovely references there that you can use to find out more.

Computer Science and the Hour of Code

Sunday's paper had a big section on how important it is to learn to program. I agree. There was a lot of kerfuffle a few weeks ago when Lottie Dexter, a Conservative activist hired to manage a "Year of Code" initiative, admitted that she didn't know how to write software. Lots of people got very cross about that and they got even crosser when she went on to say that you can learn how to teach programming in a day or so. 

Oh well.  I think/hope that what she meant to say was that you can learn to do something useful/fun with a program and tell someone about it in one day. And I suppose that you don't need to be an active practitioner of a field to promote it. Nobody seems to expect the head of British Airways to be a qualified pilot. 

You can watch the item on Newsnight here. For me the most unwholesome aspect of the whole interview is offhand manner of the interviewer, Jeremy Paxman, who gives the impression that learning how to instruct the machines that control our lives today is somehow beneath him and that's how it should be. Oh well again. 

Of course if Lottie Dexter had said "Learning to program is very hard, takes ages,  and you need an enormous brain to be able to be able to do it" she would have been in about the same amount of trouble. I reckon I've been learning to program for the last forty years or so, and I wouldn't put myself forward as that much of an expert. But I can get useful things done. And I know (mostly) which things are impossible to do with computers.  

For me the important thing about the whole learning to program business is that if you have a go you know what you can and can't do with computers. You get a feel for what is possible and you are motivated to have a go. And maybe you'll like doing so much that you will decide to learn a bit more....

And with that I present "Rob's Things to Do if you want to learn about computers (or indeed science and technology in general)"

  • Have a go. Go to the hour of code site and have a play.
  • Don't expect to learn everything at once. One of my favourite tweets was from someone who said "It seems to have taken me around 20 years longer than I expected to become a good programmer". It won't take you 20 years to learn how to do be useful with a computer, but just like a great concert pianist is always finding new things in pieces of music and new ways to express them, programming has a lot of art in it and you are always discovering new ways to do things. But you can't ever say you've learned all there is to know about the subject. The good news though is that you don't have to.
  • Have an aim in mind. Programming is all about making things. You can't just learn it in isolation, you have to be building something. Set out to make a silly game, a clever web page, a moving robot, a musical instrument or anything that you find fun and engaging.  I'm presently trying to make some remote controlled table lights for a wedding. I've learned about a whole new branch of embedded technology and I'm still finding out new things. I'm having a great time. And I might even make some lights by the end of it. 
  • Find friends. Working together is much more fun. You can solve problems by just explaining them to each other. Join a group. Start a group. Look for STEM ambassadors in your area and find out what is going on. 
  • Keep it simple. Get something simple working and add things to it. Don't have a huge, complicated idea and then fail to make it work. 
  • Remember it is supposed to be fun. If you start to fret about whether you can make your thing work then take a step back, change what you do, or go and listen to music or play computer games for a while and then come back and try again.

I've no idea how my life would have turned out if my school hadn't pointed me at a teletype connected to a computer all those years ago. But I'm jolly glad they did. Perhaps you should take a look too. 

What does ?? mean in C#

WP_20130829_17_11_38_Pro__highres.jpg

I sent out a tweet asking folks if they knew what the ?? operator in C# does. Quite a few people did, which was nice. For those of you that haven’t heard of it, here is my explanation.

If you are a C# programmer you will know about references. The way that C# works, a variable can be managed by value or reference. A variable of value type is stored in a location in memory. For example:

int i;

This creates an integer variable called i. When the program runs the system will decide where in memory the variable should live. You can think of computer memory as a whole bunch of numbered locations. Because that is what it is. Perhaps the variable i could live at memory location 5,000. Then when we write the code:

i=99;

The effect of this is to put the value 99 in memory location number 5,000

So, if I write code like:

j = i;

This would copy the value held in memory location 5,000 into the location where the integer variable j is stored.

This is how value types work. Whenever we do an assignment of a variable managed by value what happens is that the value is copied from one memory location to another.

So, what about values managed by reference? Well, in these there is a level of indirection between the variable and the actual data. Suppose we have a class called Account, which is managed by reference.

Account a = new Account();

This statement makes a new account variable and then sets the variable a to refer to it. The variable a will hold a reference to the new Account. Perhaps the new Account will be located at memory location 10,000 which means that the variable a (which might be stored at location 6,000) will hold the number 10,000 – because that is where the Account instance is stored. The Account class might have a Name property, so I can write code like:

a.Name = "Rob";

When the program runs it will go to location 6,000 (where a is stored) and read the number out of there to find out where the Account is. In this case the variable a holds the number 10,000 and so the program will go to the Account there and set the name.

So if write code such as:

Account b = a;

This creates a new Account reference called b which refers to the same Account instance as a, in other words it will refer to location 10,000.

So, in the case of the value the information is just there in memory, but for a reference we have to go where the reference refers. With references you can also set them to null:

a = null;

This has the effect of putting a “magic value” in the variable a that indicates it really points nowhere.  It is a way of saying “this reference does not point to any object”.

The null reference is often used in programs to indicate that the thing you asked for could not be found, or hasn’t been made yet, or doesn’t matter.

This “nullability” is so useful that people wanted to be able to make values “null” as well. So they invented one.

int? ageValue;
The addition of the question mark makes an integer variable (ageValue) that can be made null. For example, the bank might store the age of a customer when it is important (when the age is less than 20 say) but once a person reaches a certain age, from then on the age is completely irrelevant to the system. They can mark the ageValue as null to indicate this.

ageValue = null;

Programs can also test for null

if (customerAge != null)
{
// Stuff you do if the age matters
}

In XNA you often find nullable value parameters being sent to method, so that the method can know to ignore them.

So, I’ve been writing for what seems like ages, and I’ve still not explained what ?? does.

Well, ?? provides a convenient way that I can map the null value of a nullable variable onto a specific value

int actualAge = customerAge ?? -1;

It saves us having to write code that tests for null and sets a value appropriately. The above statement sets the value of actualAge to the value in customerAge unless the value in customerAge is null, in which case it sets it to –1.

if (customerAge == null)
actualAge = -1;
else
actualAge = customerAge;

In other words ?? is a short form of the above test.

Kids Can’t Use Computers?

DSC02256_7_8.jpg

A while back I read this post titled “Kids Can’t Use Computers – And This Is Why It Should Worry You”. It depressed me. Not because I agree with all of the sentiments of the author, but more because I worry that people may take this kind of viewpoint seriously. The underlying tenet of the article (I’ll save you the bother of reading it) is that only a few people can actually use computers, especially kids. And this is apparently a bad thing.

The author brings out a collection of “horror stories” of people who “can’t use computers” for one reason or another, including not knowing that their laptop has a WiFi off switch. It says a lot for the nature of computer folk that a good portion of the debate following the post is an earnest discussion of whether or not laptops should have such a switch. I’ve actually been caught out by this myself, and therefore, by definition, am unable to use a computer. Oh well. Back to the drawing board for me.

The author completely misses the point that it is perfectly reasonable to expect that things should just work. Engineers have been very good at producing products that “just work”. I can remember when starting a car in cold weather was a tricky affair which was involved lots of fiddling with the choke and pumping the accelerator pedal. Nowadays you just push a button.

Cars have been around for well over a hundred years, and their fundamental function has not changed over that time. Computers have been around for much less than half of that and we are still discovering new things we can do with them. I think it is safe to say that we have a much better handle on how to make a useable car than we do a useable computer. Which means that people will sometimes have problems getting their systems to do what they want.

The current generation of computer hardware and software is very prone to failure when confronted with frailty of human nature in all its forms. But people will translate their experiences with their cars to computers. Why should the computer not just work when I press the button?

It is interesting to watch kids use technology, to see them running their fingers over the TV screen and expressing surprise when it doesn’t respond to their touch. To see them start watching a video on an iPad and then become confused when the video doesn’t just continue on the TV when they turn it on. They are going to see these things as omissions that need to be fixed, not evidence that they are too stupid to use those devices. And quite right too.

So what do we do about it? The author suggests a “back to basics” approach so that everyone can learn as much about the low level functions of computers as he is evidently proud of knowing. Then we can all argue about the best version of Linux to run on a mobile phone while our kids throw things together and build the future out of what sticks. Just like it ever was.

It is very important to learn the low level stuff, to have an understanding of the limitations of the computer, what they are really good for, and how you get them to work for you. Learn to program. Absolutely learn to program. But then use that ability to make things and have fun making things. Take ideas (silly and otherwise) and give them life. Spread them round. Build solutions and games that make people happy (or at least smile). Learn about the technology by playing with it. If it turns out that your ultimate interests lie outside the realm of processors and memory then that’s fine, but an understanding of what a computer is good for and how you make it work is always really useful to have.

Never regard your skill with computers as marking you out as in any way special unless you can do everything else as well. I can write code, but I can’t draw for toffee. If an artist comes to me with a computer problem I’ll not call them stupid if I can solve their problem and they can’t. Because I can’t do what they can. 

A proper computer professional is as good with people as he/she is with computers. In fact, bearing in mind that a lot of computing is finding out what people want and then making a happy ending from their wishes, I reckon that good inter-personal skills are more important in computing than they are in just about any other field. Work at these as you would a new programming language. And learn to write well.

For me computing is all about having fun making stuff and engineering happy endings. I’m not looking for a future where everyone is “clever” enough to use a computer. I’m looking for a future where we have enough people around who are able to produce compelling and useful applications for those who want to use computers to make their lives better. In other words, computers should “just work” and we should have folks around who are skilled enough to make this happen (and enjoy doing it).

Writing with Colour at the Guardian Masterclass

DSCF3564.jpg

Anyone can write, just like anyone can cook. As soon as you move from restaurants and ready meals to getting ingredients and mixing them in pans you can start thinking about getting a white uniform and people shouting “Yes chef!” to you across steam filled kitchens. Moving beyond shopping lists and one line Facebook updates means that you can start pondering putting “writer” on your business card and extracting killer quotes from unresponsive interviewees. Or then again, perhaps not, because of course the really important thing is what everyone else calls you.

If you are the only person that thinks you are the next Jamie Oliver then you might have a hard time getting folks to eat your food.  And while the internet does provide a potential audience of billions, getting them all to come and read your web site will take more than just your idea of deathless prose. This means that you have to do the hard stuff, like practice and learning how to get better.

I’ve never dared call myself a writer; I’m more someone who throws a bunch of words at a blog post every day to see which ones stick. But today I went along to a Guardian Master class called “Writing with Colour” to find out a bit more about this writing business. There was actually another reason for going as well, the sessions were being given by writers who I’d long admired from afar, and I liked the idea of admiring them from a bit closer up.

There were about 80 or so of us on the course, which took place in the actual Guardian newspaper building in London. The sessions were all great. If you have a low opinion of journalists and editors then you should go along, just to find out how thoughtful and considered these folks are about what they do.  I’m pretty sure that not all writers are like this, but these were folks who I’d be happy to listen to all day, which is just as well, because that is what we did.

A few of my thoughts from the sessions:

Read what you have written. Out loud. All the writers took evident pleasure in reading what they had put on the page. This is as confidence thing I reckon and darned good advice. Sometimes you might like what you hear. If you don’t like it, go back and change it until you do.

Be loyal to your work. This can mean a bit of internal wrangling as you seek permission to print that quote from a reluctant interviewee. It might mean you can’t be a totally nice person all the time. And it might mean dropping that wonderful sequence because it doesn’t add anything to the piece.

Always deliver what you were asked for. Someone asked Lucy Mangan what she did if her four o’clock deadline came along and she hadn’t thought of anything to write about.  Her reply was brilliant. That. Does. Not. Happen.  If you are a proper writer and you are asked to write something that’s what you do. You can wrestle with your inner demons about the content (and you should) after you have pressed the send button, but the important thing is if you are asked for 550 words you should deliver 550, along with a convincing pitch for why you should be allowed another 200 or so.

Always edit, and always cut. The editor is the person who makes things better and tighter, sometimes by cutting out what the writer thought of as the best bits. If we end up losing the traditions of print journalism I reckon the editor is the person we will miss the most. This probably means that writers will have to spend more time editing their own work. So try to do this.

Work at what you write. I was very pleased to find that nobody said that they found writing easy. Everyone said they had to work at it. Interviews take preparation and persistence in writing everything down. Features take research and rewriting.  And the work doesn’t stop when the piece is finished, everyone valued re-visiting items and look at why they wrote what they wrote.

Seek out the colour. Work to find that killer fact, or interesting angle, which will give you a hook to hang your words on or will be quoted in the pub by your readers. If you are very lucky the colour will find you, but mostly you find it in the research you did, or the huge pile of notes that you made.

Last week I sent a jaunty tweet to the organisers saying how I was bringing along some crayons, as the subject was “Writing with colour”. I can imagine the sinking feeling in the stomach of the recipient, along the lines of “We’ve got a right one here….” Sorry about that.

Anyhoo, I found the whole affair really stimulating, and if you want to get tips about improving your writing style, and maybe meet a few heroes, then it is well worth the price of admission. And the lunch was good too.

DSCF3560_1_2.jpg

Think of the Audience

DSCF0504_5_6.jpg

Some time back I wrote a blog post about the most important thing in a project. To save you the trouble of reading it again, I concluded that the biggest risk that any project can run is that you might not  be able to make it work.

I’ve been thinking about presentations in a similar light having seen a bunch over the last week at the Imagine Cup. So, what’s the most important thing in a presentation. Is it the script? The demos? Running to time? The jokes?

Actually I reckon it’s none of these things. The most important thing in any presentation is the audience. If you don’t build your presentation with them in mind then it will not go as well as it should.

Thinking about the audience begins at the start, when you worry about whether or not what you are going to say will make sense, has the appropriate level and the like. I reckon that the thing an audience likes the best is a story, so presentations that have some kind of narrative flow are going to go well.

During the presentation you should be watching the audience to make sure that what you say is going down well, and don’t be too afraid to change tack. Asking questions to confirm that you are going in the right direction is a good idea too. It builds your confidence and establishes a rapport.

If you are now thinking “Great, now I have to worry about watching the audience as well as everything else…” then I’m sorry about that, but I think it s something to keep in mind. For me the worst presentations are where the presenter just talks at the audience. You should try and make the presentation a conversation as much as you can. With very large numbers this can seem a bit daunting, but remember that an audience of 10,000 people is actually made up of 10,000 individual people.. If you think in terms of talking to just one of them, then that will help you manage this.

For me the best presentations I saw last week were those that engaged the audience from the start. So see if you can do the same when you stand up and start talking.

Heading for London

DSC_0196.jpg

Ian Livingstone playing the game that got us to London. He reckons we should set it in space, and I think he might just be onto something….

To start with, a bit of history. What seems like ages ago David, Simon, Lewis, David and me took part in Global Game Jam Hull. And we built a game. Then Microsoft offered a prize for the best Windows 8 game that came out of the Game Jam and made it into Windows Marketplace. So David and Simon took the game engine, made it marketplace ready and shipped it. And Heartotron won. At the time we weren’t sure just what we had won, but part of the prize turned out to be a trip to London to tour a game development studio and meet up with some of folks who made the game industry what it is. And so we found ourselves on a train at 8:00 am in the morning, speeding through the sunshine and looking forward to an interesting day.

Which we got in spades. It was great. First up was a look around Lift London, a shiny new Microsoft game studio with a focus on making games the Indy way. No big (or at least huge) teams, flexibility, appropriate technology and total commitment to the product are the order of the day. Lift London also sees incubating fledgling games developers such as Dlala as part of their remit, which is very interesting.

With people on the team who can say things like “..and then we went on to write Banjo-Kazooie…” or “..and then we did Singstar..” alongside folks who have grown up writing and pitching games any way they can I reckon we can look forward to some fun stuff in the future.

We got to look at some work in progress, which was fascinating for me. The transition from ideas to drawings to models on the screen was intriguing.. I get very jealous of people who can draw, and loved seeing these people in action, and how they can turn out lovely looking artwork with just a flourish of their Wacom pens. Most impressive.

Then it was time to move on to Modern Jago, a pop up venue in Shoreditch, for workshop with the gaming legends Ian Livingstone (Vice chairman of Ukie, Games Workshop founder, president at Eidos), Andy Payne (chairman of UKIE and CEO of Mastertronic) and Philip Oliver (TIGA board member and CEO of Blitz Games Studios).

Each had plenty of time to speak and plenty to say. Some things that I took away, in bullet form:

  • There has never been a better time to be writing games. Cheap tools and an easy path to market give you amazing potential.
  • There has never been a more competitive time to be writing games. The statement above is true for everybody.
  • Put your monetisation in at the start. If you are going to sell your game, be up front about that (although recognise that very few people will part with cash to buy it). If you have a pay to play model, put that in the central game mechanic. It is impossible to add it later.
  • Use metrics and feedback. Track downloads, watch for reviews and scores, use telemetry to be able to tell how far people get through the game, how long they play for, and when they give up. Phase your releases so that you get feedback from one part of the world (for some reason Canada and New Zealand are popular for this) before you go global.
  • Look for the “soft” market. A big splash in a small pond with a future has more potential than trying to make an impression in a huge marketplace with scant resources.
  • Get a following. Napoleon reckoned that with 1,000 followers you have an army of your own. He wasn’t on Twitter, but you can be. Give opinions and help to people out there and build a following of folks who like you. A crowd who like what you do and want to see what you do next are great to have around. Be loyal to them and they will replay you by supporting what you do.
  • Get a job. You might plan to be a lone gunfighter releasing your fantastic stuff for the world to marvel at, but it much easier to do this with a roof over your head and a full stomach. One of the things you need to succeed is luck (everyone said this). Napoleon (him again) reckoned that he always preferred his lucky generals to his clever ones. If the luck isn’t there, and it may not be, you still need to eat. Make time for your development and go at it full tilt, but there’s nothing wrong with having a backup plan.
  • Get some “skin in the game”. This kind of goes against the above but I still feel it is something to think about. If you feel that the stars are aligning and that this is “the one” then feel free to go for it every way you can. Living in a van for six months while you raise funds and build your product base might be the thing you have to do to achieve success. Worst case maybe your boss (see above) will have you back – particularly if you part on good terms.
  • The three most important aspects of a game are playability, playability and playability. But graphics and high production values are a way to distinguish your product and get people in to discover just how good your game is. But this, of course, costs money and time. As does buying a place in the charts that gets you noticed, something else which might be a necessity.
  • Put yourself out there. I was particularly pleased to hear this one, as it chimes with what I’ve thought for years. You need to be able to do the “front of house” stuff. This is really bad news for software developers, who tend not to be the most extrovert folks, but it is a necessary skill. Get yourself in front of people. Practise doing stand-up, meeting and greeting and networking. If you don’t have these skills other people will not compensate for your lack of them. They’ll just find someone else more interesting to talk to. Ian Livingstone himself said that this is one lesson he took a long time to learn. The great thing about computer folks is that they are used to picking up new tools and APIs. Treat this as just another thing you have to learn and get good at.
  • Make a good story. The press is interested in you, but only if you are interesting to them. “I’ve made a fishing game” is not useful to them. But “I’ve made a fishing game that I wrote underwater whilst wrestling a Great White Shark on the Barrier Reef” is. Make sure that you have a good tale to tell. Use your followers (see above) to big you up and help you get noticed.
  • If you are working as a team, set some ground rules (another favourite of mine). Have a plan for what to do if your lead developer gets a “proper” job and stops writing your game engine. Have a protocol and a policy for re-negotiating your arrangements when these events happen.
  • You don’t need to be the best, or cleverest. Just there are the right time, in the right place, with the right thing. Try lots of things, in lots of places as frequently as you can. Don’t expect success to happen the first, second or perhaps even the third time. But as soon as you get a sniff of something that seems to be working, follow it, develop it and ride it, and you might be the next big thing.

All in all a fantastic day out. Thanks to Microsoft for setting it up.

Big Risk–Big Reward

The Zone

I’ve spent a lot of the last few days sitting in on Seed exit interviews. These are actually great fun, although they are also very hard work. They are part of the assessment process for our MEng students. Essentially we get them to write a case for the marks that they think they deserve, and then they come to see us and try to justify them. For more details of the kind of things we are about, take a look at this blog post from Tom.

Anyhoo, the meetings take around an hour each and they can get pretty intense. Students put very strong arguments that they should get 5 out of 5 for a particular category, and we have been known to revise their scores up as well as down. One of the assessment categories has to do with planning. This is always an interesting issue. I made a point of heading straight for the Risk Assessments that we get the development teams to produce for their projects. These are supposed to set out the major risks to a successful outcome of the project.

Managing risk is a very good plan in a project, most of the projects that fail do so because of a failure to identify and track the things that could go wrong. But sometimes folks didn’t seem to quite get the whole story. Most of the Risk Assessments covered things like data loss, changes to personnel and the like, but some missed out the most important risk of all.

“What if we can’t get it to work?”

It is not unknown for a project in real life (and our projects are as close to real life as we can get them) to fail on this one. The system can have a beautifully crafted user interface, a carefully targeted audience and snappy marketing but if it doesn’t work, all this comes to naught. If you ever, ever, get into a development project you should make it your business to put this in the Risk Assessment and then track it. Maybe the Risk can be removed really quickly, once you’ve built a working prototype. Maybe it’s a slow burner, when you have to do a bunch of work and wait on other people before you find out whether it is a workable proposition.

I make this point as often as I can, and I often get the response “Well, Duh! The project is all about making this thing work, why would you add this as a risk?”. That’s true, but I know about projects, and people, and that defect in human nature that tends to push tricky things away into the distance where you don’t have to think about them too hard. Much easier to design that pretty user interface than work on that nasty interrupt handler code, or whatever.

With experience you learn to identify the “stoppers” in a project; the things that, if you can’t make them work, render the project a failure. These go onto the Risks and are tracked regularly to make sure that nothing in the project is built on sand. By the end of the meetings I think that the students we saw had taken this point on board, which I think is a one of the many really useful outcome from this part of the course.

How to Fail your Assessed Course Work

sunset 006.jpg

First a note. We don’t have many people that actually do fail their coursework (although, years ago I did manage it by using a variant of this technique involving punched cards). But over the years I’ve seen enough of these to be able to produce a comprehensive guide. This is the sequence that I have found works very well when it comes to failing a software development project. Just follow this fool proof set of instructions for guaranteed failure.

  • T-minus 8 weeks: Assignment distributed. Decide to ignore it for now. Put on desk.
  • T-minus 4 weeks: Happen to find assignment under pile of dirty socks. Take a quick look. Seems easy enough. Decide to do it later.
  • T-minus 2 weeks: Find the assignment again and experience a mild twinge of panic when you look at the submission date. But no time to do it because other coursework is due in now.
  • T-minus 1 week: Decide to complete entire program by performing herculean development effort over the coming weekend. Feel much better. Go to pub to celebrate.
  • T-minus 2 days: Fire up Visual Studio and write 300 lines of code in one sitting. Which won’t compile. And actually you’ve no idea what it does. Stay up until 2:00am trying different combinations. Ask a chum who has just come back from the pub to take a look. He suggests adding a bunch of curly brackets and semi-colons. Code now compiles and runs. But you still have no idea what it does. Fall asleep at desk and wake up after six hours with key shaped bumps in your cheek.
  • T-minus 1 day: Program now fails to compile again after you pasted in some code that you found on the internet that looked like it might do what you want. Decide to seek help. Post a plea for help in a question on Stack Overflow.
  • T-minus 12 hours: Check Stack Overflow for answers. “SuperDev99” thinks you should use recursion. “P-Guy” thinks you should really use Python. “Troll95” posts that all C# developers are ugly and stupid.
  • T-minus 6 hours: Having had no sleep for 20 hours you decide to re-write the entire system from scratch. It seems like the only way. You write another 300 lines of code. That won’t compile.
  • T-minus 1 hour: Program now compiles, but it is alternating between crashing instantly and causing the computer to lock up. Check Stack Overflow again. Find that someone has posted a complete solution to your problem. In Prolog.
  • T-minus 10 minutes: Submit program that compiles, runs and prints “Sorry about this” in large friendly letters on the screen. Oh well. There’s always the resits.

Now, of course, nobody actually does all of this. Although I’ve managed most of these tricks at one time or another. Please, please, if you get some coursework, frontload it. Have a crack at the code as soon as you receive the specification and then play with it in the run up to the due date. You don’t have to write all the code at once (in fact this is a bad plan) but you should keep noodling along with the system over the weeks leading up to the hand in. And seek help if you hit problems.

The internet is often very useful, but beware of using downloaded code. Often you end up trying to use some code you don’t understand to solve a problem you don’t understand and getting errors that, wait for it, you don’t understand. Much easier to take your problems down to the lab or to the person in charge of the coursework and get them to help. If you want to post questions, use the forum or departmental Facebook group. At least the folks there will have an inkling of what you are doing and why.

By the end of my university career I was getting reasonable marks for coursework, and this was mainly down to a “starting early” technique.

Start your Own Business. Why not?

DSCF1601_2_3.jpg

Liz Johnson from the university Knowledge Exchange gave a Rather Useful Seminar on starting your own business today. We had a very good audience which was nice to see. The great thing about a Computer Science student is that they already have a bunch of skills that can actually drive a small business along.

There were some great tips for getting started.

Let people know that you are running a business

People like HMRC (Her Majesty's Revenue and Customs) like to be told if you are earning money. If they find out from someone else that you are working – which is pretty much guaranteed as soon as you get paid something by another company – then they might get upset and give you a hard time. Your landlord might need to be told if you are working from home, particularly if you customers back to your place for meetings. This will also affect your household insurance. If you are driving to customer meetings and delivering stuff make sure that your car insurance covers this. If you are starting a business alongside an existing job, it makes sense to tell your employer. They could get rather cross if they find out, and you might be able to work with them to leverage some useful synergy (proper business talk eh?)

Cover yourself in respect of liability

Perhaps the most important one here. Make sure that you have insurance that will cover you in the event of a dispute with a customer. Nobody starts a job thinking that it could all go wrong and you could get sued, but it can happen and you need to have protection. This is kind of expensive, but you can pay by instalments, or get insurance for each job in turn. The price of not doing this is very scarily high.Of course this insurance will count as a business expense, so you can count it against tax that you would be paying on the work.

Take Care Over Your Name

If you are going to give your enterprise a name, spend some time picking a good one. Practice saying the business name and make sure it sounds good to you. Think how it would sound to someone who rang you up. (I thought this was wonderful advice). See if you need to protect your name, and make sure that you are not using the same name as someone else, that could end really badly.

Get Help

You will need as much help as you can. Use skills from helpful family members, even if it is just as a sounding board so that you can make sure your ideas aren’t too wacky. There are lots of agencies who can help you find grants and all kinds of other things, starting with the Knowledge Exchange on the university campus. The Platform Expo folks in Hull are also a great source of resources, particularly if you need things like office space and help setting things up. Look up Microsoft BizSpark for free software.

One piece of advice that I heard from another source was that if you are not sure whether or not you need funding, you probably don’t. If you need money, for example to buy a new machine or some stock, you will really know that you need it. Don’t just think you need to get cash just so you can get started. If you have your trusty laptop, a good network connection and can afford to live, then for a developer that is probably all you need.

Do what you like

If your business is a success you are going to be spending quite a lot of time doing it. So try to find something you enjoy doing. If you have a hobby that could become a business, that is not a bad way in, either way, if you do it right you should avoid the “Monday morning feeling”. And maybe even become rich.

If you want to find out more, go here:

http://www2.hull.ac.uk/administration/enterprise.aspx

Black Marble Wisdom

DSCF1577.jpg
Steve Spencer and Rob (Boss) Hogg get down to business

We were very lucky enough to have Steve and Rob from Black Marble come over to Hull today to tell us about the business of software development. I think everyone should see talks like those, particularly people who think that creating software solutions is a technical problem. Because it isn’t. It’s pretty much an “everything else” problem with a bit of technology thrown in to make it work. Steve and Rob give about the best exposition of this that I have ever seen. They can talk about the mistakes that developers and managers make because they are candid enough to admit that they have made most of them over their time in business.

The staggering number of software projects that fail in the real world is down to human frailty as much as anything else, and what Steve and Rob do is point out the behaviours to watch for and the strategies that you can use to mitigate the problems.

My only regret about the talk was that we did not have more students there to get the benefit of it. Folks, if you thought about going but didn’t bother in the end, you have seriously missed out. With a bit of luck Rob and Steve will be back again next year, and you can get the benefit then.

Class Design for Shops

IMG_6213_4_5.jpg

At the moment lots of our students are working on their first year coursework. This year they can make either a game, which I’ve called “Space Killers” or a management system for a record shop, which I’ve called “Vinyl Destination” (turns out that there actually is a shop with that name – which only goes to show that great minds think alike sometimes). By the way, a record is what very old people used to buy music on. They are pressed out of plastic, usually 7 or 12 inches in diameter, easy to scratch and becoming fashionable again, which is nice.

Anyhoo, one of the central design decisions that has to be made is just how to store information about the records that the shop has in stock. We have been discussing this in the lectures, and it is interesting to reflect how the business needs of the customer affect the organisation of their data. Lots of shops have things to sell, but the way that you would hold their stock information varies from one business to another. I’ve broken these down to three broad categories which I’ve called “Art Gallery”, “Car Showroom” and “Supermarket”.

Art Gallery: In an art gallery each item of stock is unique. Or at least it better had be. Turning up with a second copy of the “Mona Lisa” would probably raise one or two eyebrows. Every item in the gallery has properties such as the artist or artists that made it, the date, the description and the price, but this information would be held for each individual piece in stock. To store the data for this application we would design a class, perhaps called “StockItem”, and then create an instance of this class for each of the pieces that is held in stock.

Car Showroom: This situation is slightly different. The showroom will hold a large number of cars, but they will be of particular models. They will hold a large number of “Ford Fiestas”, but each of them will have different trim levels, colours, ages and prices. If we held the data about our cars in the same way as we hold the data in the art gallery we would store a lot of the same data multiple times. Every individual StockItem would hold its own copy of the name, the manufacturer and lots of other information common to all Ford Fiesta models. A better way to design the system might be to have a class, perhaps called “CarModel”, which holds all the information about the type of car (all the “Ford Fiesta” parts) and then have the “CarModel” class hold a list of all “StockItems”. The StockItem class would hold all the information about a particular car, including things like colour, mileage and price. The CarModel class could hold a list of the StockItems of that particular model. For example, if the garage had a red Ford Fiesta and a blue Ford Fiesta there would be a CarModel object for Ford Fiesta which holds a list containing two items, a StockItem for the red one and a StockItem for the blue one.

Supermarket: In the case of a supermarket which is selling cans of beans, all the cans of beans of a particular type are identical. In this case we don’t need to store information about any individual can, instead we just want to know how many we have in stock. So for the supermarket we just need an object that holds a description of the item and also contains a counter that tells the system how many of that item are in stock.

If you are building a system for a customer, it is worth considering which of the three arrangements makes most sense. In terms of Vinyl Destination I reckon that because the you can get records of different quality it is more like a garage or an art gallery. The shop may have several copies of “Abbey Road” by The Beatles, but some will be in pristine condition (and therefore worth more) than others.

You get what you pay for

Untitled

Some years ago we were helping dad move house. Having loaded up we headed onto the road. As we rounded our first corner we heard a horrible sliding noise from the contents of the van followed by an enormous crash. Tim, who was riding shotgun next to me, said “Ah well. You get the help you pay for”. Of course none of us were professional house movers, we were just helping dad out. And it turned out that the enormous crash was caused by a box of cutlery, so no harm was done. But the remark has stuck with me.

I was reminded of it when the terms and conditions for Instragram were changed recently, and people suddenly found that things they thought they owned (i.e. the pictures they had taken) were now ripe for exploitation by the company that was storing them. Instagram decided that they could use any of the pictures held on their servers for profit and advertising. There has been something of a backlash against this, and as a result some back tracking on the part of the company, but I think it has opened up a useful debate. Perhaps, as a result of it, paying for things will come back into fashion.

I’ve always been deeply suspicious of free services. For a start they can vanish or change at any moment, taking with them stuff that might be important to you. And of course, as the saying goes, if you are not paying for the service, you are the product. Facebook sells its ability to target you with custom ads. Google surrounds your Gmail inbox with links to “related services”. And if you ever search for anything (for example my quest for an oven) you will find yourself haunted by matching adverts in every web page you visit for a while.

If something is important to me I’ll pay for it. I put my pictures on Flickr and have done for ages. It costs me around 24 dollars a year to do this, but I can now complain to the site if they ever get lost, and Flickr don’t have to sell my photographs to stay in business.

Maybe in the long term the price of service provision will drop to the point where companies will be able to provide the service for a small fee, rather than have to hawk around personal data for profit. Flickr are obviously keen to cash in on this, and have just launched an offer of three months free hosting to try and tempt people away from “free” sites.

Taking One From The Team

IMG_5551_2_3.jpg

One of the Second Year courses that I help deliver is our Software Development module. As part of that we put our students into teams and get them to write some software for a picky customer. They have to deal with dodgy legacy software and the fun and games that is associated with working as part of a team.

One of the rules that we have is that everyone in a team should write some code. Not all of it, but some of it. One of our worries is that in a team of 6 people we might get a couple of folks who will say “We’re the best programmers here, we should write all the code” and then go ahead and try to do just that. This is bad in many, many ways.

For a start, they might not be the best programmers there, just the ones with the biggest egos/mouths. For another thing, they might not be able to do all the work with just two people. But most importantly, if they are the best programmers around, and they could write all the code they should still not try to do it. Because from a learning outcome point of view they are missing out on a huge opportunity.

If the “great programmers” just churn out the code all they’ve done is reinforce their high opinion of themselves. But if instead they decided to piece out the work sensibly and then spend some of their time mentoring those who are less confident coders so that everyone gets better at development, then they are picking up an incredibly valuable skill. The ability to teach people stuff is really useful, even if you have no intention of going into teaching. When you try to explain something to another person you have to try to put yourself in their position and then find a context which they understand, into which you can put the information you are delivering.

The skill of being able to explain something to another person is very valuable, and it is just the kind of thing that employers are looking for. It also makes you more confident in interview situations, just because you are better at talking to people.

So, don’t think that offering to write all the code is “taking one for the team”. It is more like “taking one from the team”.

Writin’ Skilz R Important

IMG_0449-Edit.jpg

If I had one piece of advice for a Computer Science student I think it would be nothing to do with programming. Or even computers. It would simply be “Learn to write well”. This doesn’t mean I necessarily want to see short stories, or poems (although send them through if you like), it just means that the art of putting words our there that make sense is something you should work at.

In my experience the only way to get good at writing is to write a lot. Then write some more. Blogs are great for this, as are diaries. And Final Year Projects. Just set yourself the task of knocking out a few words a day and putting them somewhere where others can find and comment on them. Try writing in other styles, from the dry “It can be shown that” kind of report style to anything else you like, including murder mystery if you fancy having a go. And get used to revising your text after you have read it. Just because there are no wavy red lines on the page doesn’t mean it actually makes sense. Watch for repeated phrases that repeat themselves repeatedly. Try to find alternatives to make the text sound better.  A good tip is to read out loud what you have just written. Anything that is not quite right will really sound  that way.

Another tip is to read stuff by people who can write well. The BBC news site is pretty good for this, along with newspaper sites like the Times and the Guardian.

I’m not saying that Computer Scientists are now doing an English degree. What I’m really saying is that if you can express yourself in written words, this will pay off big time when you go for jobs.

Rather Useful Seminars

DSC_0048.jpg

I'm organising a sequence of "Rather Useful Seminars" for this Semester. These will be for any students in the department who want to come along and learn stuff that might be rather useful. You can find more about the seminars here:

 /rather-useful-seminars

The first one is this Wednesday at 1:15 pm in Lecture Theatre D (LTD) in the Robert Blackburn Building. It is about participation in the Microsoft Imagine Cup. This is a student competition in which Hull has had a lot of success, and I'd like to have some more.