Big Risk–Big Reward

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.

Future Imperfect

Everyone should read this:

http://www.guardian.co.uk/technology/2013/may/19/driverless-cars-pilotless-planes-jobs-human

The future that is described is quite believable and rather worrying. Particularly if you drive a lorry for a living.

How to Fail your Assessed Course Work

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?

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

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

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

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

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

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

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.

Project Deliverables

I really like having the students back on campus. I was talking to Cameron about Seed projects. He is on the fourth year of our MEng course and he will be developing a project for a proper customer as part of his course this year. He was asking for any tips about project management. I told him that the best way to regard a project like this is to consider that the outcome of the work should not be a product, it should be a happy customer. If you think you are making a Stock Control System then you will focus on the technical deliverables and probably get them working, but you might not provide what the customer wants. If you think about the problem in terms of making “Wonder Widgets” happy about the way they are now able to manage their stock that puts a different perspective on the job.

This doesn’t mean that you have to do everything the customer wants, including washing their car. What it means is that you should engage with the customer as much as you can (or they will let you) when you are building the solution. We have found that the best Seed projects are the ones where the customer really gets involved with the team making their solution. The best way to do this is to make it easy for the customer to work with you. Bring things to meetings to talk about and leave with lists of things to do. And keep the cycle as short as the customer will let you. Thinking “We’re OK, we saw the customer last month” is kind of dangerous, in that this is the way you end up with a half working solution to the wrong problem.

Welcome To Hull 2012

That reminds me, must get down there and stock up before my first lecture…

Welcome to Hull for new students. And welcome back to everyone else. Firstly I must apologise for the horrible weather. My fault entirely. I washed both cars yesterday. Fool.

Anyhoo, each year I put up a bunch of tips for new students, so here goes for 2012:

1. Make sure that you have all your updates installed on your system. It doesn’t matter whether it is a Windows PC, a Mac or a Linux netbook. Find out how to check for updates and get everything up to date. At some point you will want to connect your machine up to a campus network of some kind, and if you don’t have all the latest security patches you may be vulnerable to infection.

2. Do something about viruses. At the very least make sure that your Windows PC has Microsoft Security Essentials installed and running, that the databases are up to date and that you run scans at regular intervals. If you really want to install an anti-virus program don’t feel obliged to spend a lot of money, the AVG free anti-virus program is good and will cost you nothing. Get it from http://free.avg.com/. Please don’t spend huge amounts on some of the more expensive ones. The benefits are dubious and they also have annual renewal charges too.

3. Take a backup of your machine and leave it somewhere safe (perhaps even at home). Find out how to use the backup software on your machine and take a copy of everything. Use one of these cheap external hard disks that you can pick up for around 35 pounds or so from places like http://www.ebuyer.com/ or Staples, or even Tesco. That way if it all goes horribly wrong when you get to university you can recover your precious music, videos and other stuff. Once you have the backup habit, take a full one one every month or so.

4. Don’t spend huge amounts on software just yet. Most universities (including ours at Hull) have deals that get you some programs that you need cheaply. Take a look at https://www.dreamspark.com/ for free Microsoft stuff and http://students.autodesk.com/ for free Autodesk stuff (great for 3D design).

5. The same goes for books. In the computing field they are rather expensive, and you don’t want to pay a lot for a book and then find out that it is only used for a small part of the course. You can check the books out in the library, and you might also find that there is a second hand book sale on your campus where you can pick up the required volumes from other students quite quickly. You might also want to form a little cartel with fellow students to share books between each other and spread the expense (this is also neat because it can also give you a ready made study group). Hull students will get a printed copy of my C# Yellow Book (daffodil edition). Anyone else can get it free from http://www.csharpcourse.com/

6. Get a usb memory stick (actually, if you are a Hull Computer Science student we’ll be giving you one of these later this week) . Keep backups of all your work on it. You can also use it to take files into the university to work on. You will get some filespace on the university network, but it will not be an enormous amount, and having your files always with you is useful. Put a file on the drive with your contact details (just your name and phone number) so that if you lose the drive people can find out who to return it to.

7. Get some free on line storage. I like Windows Live Skydrive: http://skydrive.live.com/. This gives you 7 GBytes of space which you can access from anywhere on the web via a browser. You’ll need a Windows Live account to use this. Skydrive will also sync files across multiple computers, although I’ve found that that DropBox has better multi-platform support and also keeps track of file generations. Take a look at DropBox at http://www.getdropbox.com/. Unfortunately you only get 2G of Dropbox space for free. You can also use Google Drive: https://drive.google.com

8. Make sure you have insurance for all your nice toys. It would be terrible if they got stolen or damaged before they were insured. Take a look at cover from student specialists like Endsleigh:

   https://www.endsleigh.co.uk/student/student-insurance/

   (if anyone knows any cheaper deals feel free to let me know and I’ll update this post)

9. Start blogging. Good writing skillz, like wot I have, are very valuable and make you a much more employable person. Sign up at Hull Computer Science Blogs: http://hullcompsciblogs.com/ and start putting your word out and building your brand.

10. Don’t worry. Really. You’ll be fine. And it will stop raining. Probably in April.

More On Broken Software

It’s not as if I’ve been lying awake at night worrying about writing software (OK, perhaps slightly) but I have been pondering the “Is everything broken?” question a bit. And I’ve come to the conclusion that, at the end of the day it probably is, but then again it doesn’t really matter that much.

All of the terrible examples that are quoted are irritations in the great scheme of things. Nobody has been hurt, nobody is going hungry because of them and if the worst thing that happens to you in your life is that you can’t put any more music on your iPhone then I really, really, want a life like yours. True, it is annoying that things don’t always work as they should, and true, it would be nice if people felt moved to provide higher quality than they sometimes do, but at the end of the day stuff mostly works, and that is the important thing.

Technology now lets us do things (albeit imperfectly) that we just could not do before. It is also a great leveller. The Queen might have an iPhone that is covered in precious stones (although she might deem that a bit tacky) but she can’t do anything with it that you can’t do with yours. Although she might not worry as much about roaming charges as you do. The best phone in the world, whatever that is, can be obtained by literally millions of people, not just one or two. And, what’s more, anyone can make programs and sell them on the devices, providing a path to riches that just wasn’t there in the past.

I think, at the end of the day, we are always going to be upset with the status quo, and want it to be better. I vividly remember reading a piece some time back that was written by a retired general type. He was moaning about the way young people were more useless and lazy than he was in his day, and how their lack of discipline and application would lead to the collapse of civilisation as he knew it. Turns out he was a retired general from the Roman Army and was writing this a few thousand years ago.

The best thing to do is to take these issues on board, try to move things on a bit and give our children something even more fantastic to complain about when they get to our age.

Update on 2012-09-18 11:20 by Rob

Case in point: At coffee mention the "Monty Python Fish Slapping Dance" and then, within seconds, be watching this.

On Broken Software

Both Scott Hanselman and John Batelle have been having problems with their software over the last week. Both their posts are well worth a read.

Years and years ago Gerry Weinberg wrote "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilisation". Not much has changed since.

It's always more fun (and more lucrative) to make and sell new stuff than it is to mend broken old stuff. And software lets you sell stuff that isn't finished. Unlike things like bridges: "Hey, that doesn't reach the other side!", and buildings: "Hey, where's the top floor?", many faults in programs take a lot longer to show up.

With a program you can leave out error handling, load testing and all the other boring bits that make a program properly useful and still ship a product that will sell by the boatload. With a bit of luck not that many people will notice. Of course, you could spend a lot more money and time getting it right. Snag is, I don't think that anyone would stay in business today making completely perfect software that took ten times as long to write as the current state of the art. People will go for new and shiny over old and working most of the time I'm afraid. I don't think I've ever seen an Engadget post about a new version of a product that is exactly the same as the old one, but works properly.

I’ve been writing software for an unfeasibly long time and some of it has wound up in the hands of proper users. I pre-date objects, Test Driven Development and pair programming. I wasn’t there when the loop was invented, but I I think I saw it in the papers. When I write a program I worry about everything, particularly what could go wrong. To me “The Happy Path” is an aside. I’m spending all my time fretting about “What happens if the response never comes back?” or “What if I get millions of these when I only asked for five?”.

It drove me nuts when I found out that the standard input/output libraries in C didn’t actually check the length of what was given to them, making the potential for buffer overrun part of the run time experience. I wrote my own input validation suite. I put it in all my products. I added timeouts everywhere. I didn’t particularly do this as part of a methodology, I just did it because it seemed sensible at the time, rather like a builder would make the ground floor before starting second floor. My programs hardly ever went wrong. Even the really big ones.

As a person who also teaches programming I try very hard to make sure that students take this approach when they write code. We start with defensive techniques and move on from there. As soon as you have a need for a number (say perhaps the age of your customer) then start to worry about how it might go wrong, become negative, very large, or change by more than 1 after a year. I don’t see this as tied to any particular methodology, I just see it as common sense, and I really want my students to have the same mind-set when they write their programs.

Modern development environments give you a lot more tools for making products that can be more reliable. Of course, the flip side is that the products can also do a lot more and that the demand for new, innovative solutions delivered in record time has never been greater. For me the only really good news is that where it is important to get code really right, for example in cars, airplanes and nuclear reactors, the software industry does seem to be able to deliver properly working systems, albeit slowly, and at great expense.

For the rest of us, I think it is as much our fault as anyone else’s that we are in this situation. We are keen to queue up for the next iPhone when the one that we have doesn’t actually work properly. Until we start only buying software that really works (and probably paying more for it) then this is how things are going to stay.

Update on 2012-09-17 09:37 by Rob

It seems only fitting that a post about software quality should hideously fail when I try to put it out there for the rest of the world to read.

First thing I did wrong was to use a poor title. Two reasons, one human and the other software. I'd copied the title from Scott's post (which is not very good etiquette and confuses search engines). I'd also included single quotes in the title text for the post, which stores up trouble should I ever be daft enough to edit it, as Squarespace then changes the title of the post,  breaking the static link to it and making the page turn into a "not found" error. Of course I did an edit, so my plaguarized post is now impssible to find. And it is about how to write software properly.

Great. Conculsive proof that the universe has a sense of humour.

Fortunately I'm equal to this. Squarespace lets me create shortcuts to pages on the site, so I can put all the broken links back. I've fixed the title, made the links work properly and all is well with the world.

Except I can still hear laughter in the distance.......

How to get more Blog Traffic

Danny Brown, one of our students, is celebrating his 10,000th blog reader. Well done sir. I tell all my students to start doing things, and get a blog out there about what they are doing. I seem to remember that Danny had a blog before he came here, but I note that quite a few Hull students are now active bloggers. You can find out what they are up to at http://hullcompsciblogs.com/ There are some really good blogs to follow up there covering everything from Raspberry Pi to video games to Gadgeteer.

I’ve been blogging for very many years and do it for fun. Although it is nice to get traffic as well. If you want some tips for a successful blog, well, here are some of mine.

Track your users. If your blogging site doesn’t provide tracking of hits then install something like Google Analytics. It costs nothing and it gives a great insight on how much activity you are getting. This can be quite depressing, but it is always useful to know when you have done something that attracts interest.

Make sure you have metadata that makes sense. I’m not going to suggest Search Engine Optimisation as such here, just common sense things to help people find you.

Integrate your blog with social media. I use Windows Live Writer (part of Windows Live Essentials) for creating blog posts. That provides plug-ins that I can use to tweet and post on Facebook when the blog is updated. You can use If This Then That (an amazing service that I must devote a proper blog post to later) to do this for you automatically. And remember that comments on your posts will not arrive on your blog posts, they will now often arrive as Likes on Facebook or Tweets.  This means that if you want to have a dialog with your readers you have to go out and look for their comments.

Some content gets a lot less interest that others. The absolute best content you can create is stuff that solves problems. If you make posts that tell people how to do things then you will get a lot of traffic as people find your answer and link through to it. You will also get traffic via search engines. Pick a subject you know a bit about, or are learning yourself, and put up blog posts with answers to the problems that you hit. One reason Danny has had so much success is that he has provided some neat technical answers (with all that a reader needs to solve the problem) along with the other content. Readers might not care about the place you went last week, or what you think about the current government, but they do like being able to solve problems. The only downside with useful content is that such readers are “fair weather friends” who will bump up your traffic for a day or so, before it drops back down again. The way to address this is to put plenty of stuff on your landing page that will encourage them to look around and find other things to read.

Enjoy your blogging, keep it regular and leave the readers thinking that you like talking to them. You don’t need to post every day. Only a fool would do that. But a regular blogging heartbeat is a good thing. If you take a break don’t worry, or feel like you have to “fill in the gaps”, just come back with a good post and it will be like you never went away.

Teaching in “Sometimes Useful Shock Horror"

If any of my students ever want to bring me a completed exam script I’m always happy to “mark” it in front of them. Quite a few take advantage of this and it really helps their grades (folks on 08120 – there’s still time before Thursday)

I’ve spent some time today going through answers and I’ve noticed something that worries me every time I see it. Some of the answers were just about spot on, but didn’t leave me with the impression that the student giving them really knew what they were talking about. It was as if they were just giving responses that they had learned, rather than speaking about something they understood. Now the thing is that this approach probably works fine if you are learning about Kings and Queens of England, but it is very different when we are teaching something that we really want you to apply. A lot of the stuff that we are teaching is intended to be applied to solve problems.

The thing to remember, if you are stuck in this revision thing, is that it is much more sensible to put effort into trying to understand the topic that it is to work really hard just remembering things. I never really got to grips with the piano because I was too “lazy” to learn how to sight read music for my left hand. So I’d just learn the left hand bit in time for the lesson that week. Of course, eventually this technique broke, when I found that the next exam had a “sight reading” test.

Learning to program is like this. You can learn “If a class implements an interface it must contain implementations of all the methods specified in the interface for it to be possible to create an instance of that class”. Or you can work out that we have interfaces so that we can build systems that deal with objects in terms of what behaviours they have (these are the methods specified in the interface) rather than the class hierarchy that they are part of.

Knowing the former will get you half the marks in the exam. Knowing the latter will let you create a mechanism whereby all the objects in your solution, the receipts, customer records, addresses, invoices and product descriptions, can be sent to a printing process that just asks them to print, and doesn’t care what type of object they really are because all the objects implement the iPrint interface which contains a “PrintToPaper” method.

If you want me to go through any of this stuff please come and see me and I’ll be happy to do just that. You can also post questions on the forum, and use the Twitter tag #08120Revision for quick questions. And don’t forget that we are not telling you this stuff so you can reflect it back to us in exam answers, we are telling you this stuff so you can use it to make things work.

I always find it amusing when students come back to me after a while on the course and say “That thing you taught us, turns out it is actually useful”.

Well, duh.

Please Do Learn to Code

Tuesday night was not a happy one in the “Land of Rob”. First off I read this post from Jeff Attwood which argued that it is pointless for “normal” people to try and learn to program. Most depressing. Then I watched some of The Matt Lucas Awards Show, a rather vacuous and self-congratulatory program where the “celebrities” were invited to identify the subjects they hated most at school. One said “Maths”, another said “Computer Science”. They followed up with examples of why they hated the subjects so much, and even brought on an obviously very talented maths teacher just to make fun of her. Ugh and Ugh.

Two sides of the same coin. An expert telling non-experts not to bother learning their subject and two apparently “successful” people who seemed proud of the fact they hated the same subject. Two rules I work by:

1. Never be proud of your ignorance.
2. Never dismiss those who you think know less about something than you do.

The only great thing about this is that today Scott Hanselman, a proper computer person and almost a celebrity, turned up with the perfect response in his blog.

Update on 2012-05-17 14:14 by Rob

This post from Alfred is pretty good too.

Tight–Loose-Tight

I don’t usually regard The Apprentice as a ready source of business acumen. Still less The Apprentice You’re Fired. But a couple of weeks ago they had a chap on, forget his name – think he runs a chain of restaurants, who said something I thought was very sensible. He talked about his philosophy for team management. He said that he used a “Tight – Loose – Tight” approach.

• Tight – get your team together and make sure that everybody is absolutely clear about what you are all doing, the part that each person must play in the enterprise and what they must deliver.
• Loose – let the people get on with it. Don’t interfere with what they are doing or insist on doing it “your way”. (He made the point that this requires quite a bit of bravery and trust on the part of the project manager)
• Tight – once everyone has done their bit, get the team together and make sure that everything has been done and have got where want to be.

I quite like these ideas, I think they are probably enshrined in a management textbook somewhere, but I don’t know much about management, I just try and get things done and make everyone happy.

Universities and Gymnasiums

Something that one of the speakers said at the “do” last night has stuck with me. He said that, with students paying more and more for their degrees there was a danger that they might be seen as consumers of education, where they were obtaining their qualification by paying for it. He suggested another way of looking at the situation that I hadn’t heard before.

He said that going to university was like joining a gym.

You can join a gym to get fit, but just joining doesn’t make you fit. It simply gives you access to machinery and expertise that you can use to get fit. If you fail to listen to the trainer or make use of the equipment then you don’t get a better body, you just get poorer.

I really like this way of thinking. I think it puts all the responsibilities in all the right places. Our job as educators is to make sure students have all the stuff they need to make progress, but at the end of the day it is the student that gets their qualification.

Best Programming Language?

There’s a program in the App Store called “Best Camera”. It takes as its starting point the idea that “The Best Camera you’ve got is the one that you have with you at the time”. The application then goes on to provide all kinds of useful tools that make the iPhone camera as good as possible.

I was reminded of this when there was a tiny bit of debate on my post about the CodeAcademy site, which teaches JavaScript. Now, JavaScript is not a great language, but it works and can be used to create useful stuff. So it is automatically a candidate for “Best Language”. In my opinion, the Best Language is the one that you are using at the moment. I base this on “Robs Rules for Programming Languages”:

1. You can write great code in any language.
2. You can write horrible code in any language.
3. The user does not care what language you used to write the program they are using. The user only cares that it works and does what they want. And that they can afford it.

I’ve written programs in loads of languages. At the moment my personal favourite language is C#, but I have really fond memories of writing embedded C, since in that I could do anything I wanted and I could build all the underlying bits myself from scratch.

This is usually the point that people say things like “But blah doesn’t have blah.” or “Blah programs are really hard to use because the debugging support sucks.” So what. This brings me to the Rob’s Other Rule

1. Having a nice place to work is much more important than the programming language you are using.

If the language you are using doesn’t have a feature that you need, find a way of programming around it. I’ve written lots of object oriented software in C. C doesn’t support objects, but I arranged the code so that it looked like it did and then programmed by “object rules”.

If the development/debugging support is horrible, wrap something around your program to make it easy to work with. I’ve built emulations of LCD panels and even lasers to avoid having to debug my programs on the real hardware. I’ve written code to make ten thousand customers from nothing, to save me having to type things in by hand. And I’ve added cheat buttons to games so that I can skip levels and inflate my scores and avoid having to play the game all the way through so that I can debug the last bits. 

Remember, when you are writing a program you don’t just control what the code does, you also control the environment the code sits in. Bending this to make things easier is something that will pay off tenfold. Can’t debug your program without a network connection? So what. Fake the web request responses so that you can feed the answers back yourself. This also makes test driven development much easier.

Of course, given the choice, you should pick the most appropriate language for the task. Give me an AI problem and I’ll be looking hard at what Prolog (or perhaps F#) can do for me. But for me programming is not about the language, it is about the problem solving, and that means a programmer should be able to turn their hand to whatever the occasion demands. Even if it is JavaScript.