Software Engineering Philosopy

This picture is one of mine. You can find it on  Flickr

This picture is one of mine. You can find it on Flickr

Had an email from a Peter who’s reading the C# Yellow Book at the moment. He asked about how to learn more about software engineering. I quite like my reply, so I’m putting it in my blog….

I worry a bit about too much emphasis on "software patterns". I just tend to write code that solves the problem, and then discover afterwards that I've used a particular pattern. Things like "dependency injection" just seem like programming common sense to me, but then again I have been programming for a very long time.

By all means read up on the different patterns, but do it from a perspective of refining your technique, not finding a quick solution to a problem. If you use a pattern without understanding how it really works that can end badly.

My strong advice is just to keep writing code. Build your knowledge and develop a habit of looking at existing systems and trying to figure out how you would make them work and what design decisions were made when they were created. If you do it right you’ll be learning new stuff and having new ideas all the time. I still am.

A lot of programming and software design is down to practice and experience, just like any other field. And you also need to remember that any working system is built up of compromises and that it is very rarely that you will find the best solution. You might find the fastest, or the smallest, or the quickest to build, but not the best.  So decide what kind of “best” that you want, and go for that.

Make a name by making stuff

Been getting some lovely emails over the last few days from people who have been reading my books, learning to program, and trying to make it "big in this business". The question seems to be "How do I get into programming/game development?". Here's one of my replies:

"It turns out that the best way to become a Game Developer is develop games.

Just have a simple (and keep it simple) idea for something and try to make it work. Take a look at the games that are in your books and see if you can modify them to behave differently. Change the images, make them do something different and then go from there.

I'd also advise you to get involved in things like Game Jams, where you can team up with other people and get help. That gets you feedback too. Global Gamejam has just been and gone, but anything like that (there might be some locally) are a good idea. 

If you can't find a gamejam, hold your own. Get some friends together and try to build a game over a weekend. Start with something simple that works and see where you go. And if you start blogging about what you are doing, helping other people and taking part in forums you'll get to know other developers and also start to make a name for yourself.

It will be a lot of hard work and you will need to be very persistent, but I know it can be done because I've seen people do it. "

Sometimes it's a good idea to pause when things are going well

Today I've been writing code. I love writing code. Perhaps too much. If a program is going well I have to reminded to do things like eat and drink etc etc. 

This was one of those occasions. But as I was munching my sandwich I came up with a way to make the program even neater. If I'd carried on at full speed I'd not have spotted this for a while and then either missed out on a trick, or had to do some rework later on. 

Having thought about this a bit more I think that it is actually quite a good idea to walk away from a programming task for a little while and go back to it, even if you are coding up a storm at the time. On any programming project (particularly programming coursework) I strongly advise people to start early so that they have time to fail. But it also means that you can stop and smell the roses every now and then, and this can make the result even better. 

What to make over summer

David was kind enough to invite me into South Hunsley School today to give a talk to some computer science students seeking a bit of direction for the summer. I wrote a few notes, and I though I'd put them in a blog post too. I

What to make?

If you have a long summer stretching ahead of you and you are wondering how best to spend it Computer Science wise, here are a few tips. 

What language?

I don’t care about the language. Anything you use to practice programming is fine by me. Sometimes it helps to use something you know, but then again you will be expected to know many languages when you go out into the big wide world. Don’t get sucked into “my language is better than your language” debates. The best language is either the one you enjoy using the most, or the one you get paid the most to work with. End of.

I like C#, Python and C, along with a bit of assembler. But things like Ruby, Haskell and Prolog are great if you want to stretch your brains a bit. Take a look at for online training.

What application?

Build what you like. Think of something you might find useful and have a go at that. Keep it simple and don’t add things. Every idea you have will make the job bigger. Write your ideas down, but don’t feel obliged to act on them. Take a look at hardware. I love the Arduino, I love robots, and I think you should have a go at this as well. You get the bonus of learning a bit of electronics too.

What for?

To find out if it is possible. To find out things by accident. For fun. It’s important to regard programming as an experimental exercise. Sometimes people write programs just to see if they work, or what they will do. Don’t be afraid to do this.

What with?

My strongest advice is to get yourself some Arduino kit and have a go at embedded development. Pick up a Sintron kit from ebay (search eBay for Arduino Sintron) and play with that. Buy one extra stepper motor and then you can think about making moving robots. Take a look here for help getting started and some things to do. 

What else?

Make sure you write about what you have done. Make a blog, get a domain, put your code on GitHub. It might be that only 10 people read about what you built, but if one of them offers you a job on the strength of it, it is worth doing. Employers prize the ability to write well and quickly, regular blogging will make you into a much better writer. And give you a destination on the web.

Moving On

The University of Hull has been part of my life for over forty years. I arrived at the place in 1975 in tastefully flared trousers and I've been here ever since as student, duty programmer, computer manager and lecturer. And today I've begun the process of moving on from the university.

I guess it stated nearly a year ago, with congratulations from LinkedIn about my 37 years in employment at Hull. I'd never done the maths before and the number shocked me a bit. It was like a bit of grit that you get in your shoe, It irked,

As the year went by and I did my various jobs I began to reflect that I've been doing the same kind of thing for a long time and, fun though it is, maybe there are other things I might like to do which would be fun too. And maybe it would be interesting to find out. The little bit of grit in my shoe got too big to ignore. 

So, today I formally informed the university that I'd like to move on from the institution on the 30th of September this year. I'll be around for the next four months, setting up courses and getting things as sorted as I can for the next session, so I'm not going just yet. But moving on I am.

It's going to be a wrench, but it had to happen sooner or later, and I really hope I'll be able to retain some links with this fabulous institution, maybe they'll let me come back and run the odd competition and deliver the occasional Rather Useful Seminar.

I've not made any firm plans going forward. With a bit of luck I'll be able to speak at a conference every now and then, and of course will rumble on. My book will be out later this year and I might think about "C# Yellow Book - the Movie", but we'll have to see. 

I've got tons of toys that I've not had time to play with, I plan to spend some time fiddling with them and writing about what happens. I've decided to re brand myself "Technical Author" just for now... Definitely not retired.

I've had a wonderful time at Hull University and I want to thank my colleagues in Computer Science and of course all the wonderful students that we've had over the years. I'm actually quite nervous about the future, but I'm also rather excited. 

Floppy Disks and Nuclear Missiles

I like writing stuff for The Conversation. They take my mangled prose and turn it into really nice articles. I've just written another one for them. You can find it here. It's all about legacy systems. 

Above you can see a legacy system I helped to make. We installed it quite a while back and saw it go from "Advanced Touchscreen Magic" to "hard to find the hardware drivers" to "replaced" over twenty years or so. I'm quite proud of the fact that I don't recall it ever crashing. Except that one time that when a chap blew up all the power supplies in the building when he was testing the UPS. And that wasn't really our fault.

We should stay in Europe

I'm going to post some of my favourite European pictures over the next few weeks

I'm going to post some of my favourite European pictures over the next few weeks

Now, I'm not a particularly political sort. My line on politics is that no matter who you vote for, the government always gets in. But every now and then I feel that I have to say something. Not that I think what I say matters particularly; it's just that I feel better having said it. 

There's a lot of kerfuffle going on about Europe at the moment. Should we stay? Should we leave? I'm strongly in favour of staying in. Very strongly. I think that leaving would be a very bad plan. There's a saying that goes "Prediction is very hard, especially about the future", so I'm not really basing my opinion on any particular "facts" going forward. It's just that I like being in Europe. I like going to abroad and feeling part of the place. I like the idea that we have some common purpose across the continent. I like the way that people come into this country and pick up bits of our culture, and bring us some of theirs. I even enjoyed the Eurovision song contest this time round (but mainly because it was very, very well done).  

Leaving Europe just seems such a cold, pointless thing to do. Are we so uncertain of our national identity that we have to prove we can go it alone? I have this image in my mind of a bunch of wagons in a circle with bears and wolves roaming around outside, and the idea that one wagon would suddenly up sticks and head out into the wilderness on its own seems unnecessary and dangerous.

So I think we shouldn't do that. 

One thing I am keen on though, is making sure that everyone has their say in this. It really is a rather important decision. If you haven't registered to vote (and you should, which ever way you feel about it) then register here

Dangerous Questions

Last week I had to ring up PayPal to liberate some funds that they were clinging on to rather more than they should. The call went smoothly and we sorted everything out. And I've since had two emails from PayPal giving me the "Opportunity to share my feedback." Or, as I put it, do their quality control for them.

I'm a helpful soul, but I'm not sure about all this. It seems that everything I do now results in a friendly request to engage in a dialogue to discuss how well it went. Even my un-solicited calls from EE about upgrading my phone were followed by a text asking what I thought. Fortunately for them I demurred on that occasion. 

I've got two worries about this kind of thing. One is there really should be more driving good customer service than the fear that someone might get a bad review. And the other is more scary. It is all to do with what my feedback tells the company about me.

As a generally easy-going soul who has no great love of upsetting folks I tend to rate my experiences in a positive way. Since my ratings can be data-mined in the context of what other people will have said about the same operatives I could therefore be placed in an "easy going" category that might change the experiences and offers that I might get if I ring up with a genuine problem some time in the future. I've been looking fairly carefully at the disclaimers and I've not found anything that rules out this possibility. 

Perhaps I should leave a really stinking review. Just in case. 

Computer Science Course in "Actually Useful Shock Horror"

James came to see us today, which was rather nice. We got to talking and the subject turned to the gulf between studies and real life, and how to narrow it.

One of the things that we try to do in Hull is to tell people useful stuff that will they can use to get by in life as a developer. A problem that we have is that people think that the only use for the stuff that we are telling them is in exams and assignments to get a good mark.  This is a good thing as far as it goes. And of course you should do this. We have to do the grading thing to ensure that the learning outcomes for our courses have been met.

But we really, really want people to carry those skills into the next (and indeed every) thing that they do going forwards. We're trying to start you building skills that will carry you through your professional career. I don't think you can ever say you've learnt something like programming because, if you do it properly, you are continuously learning. And you should never stop. 

The good news for me is that we do get a few folks who go out into the big wide world, and come back and say "You know, that stuff you taught us turned out to be quite useful".

Who'd have thought?

Anyhoo, James is very keen to come back and do some Rather Useful Seminars on what you can do as a student to build on what you're taught, which is great.  Stay tuned. 

Jupiter and Static Class Members

I put some of my lectures up on YouTube last week and it was great to get a comment on one of them. Kostas was wondering why I spend so much time explaining how static works, and even dragging the Planet Jupiter into the explanation, when a memory diagram would do the job much more efficiently. 

Well, yes and no.

The problem with diagrams like these is that people think that they just have to learn the diagram to pass the exam and therefore pass the course. But I don't want them to do that. I want them to know what "static" means, and when to use it in a program.

I use Jupiter as a context because it might stick in the memory. It turns out that the planet puts out a lot of radio static and that static on the radio is kind of like an echo of the big bang. So it has always been here. Just like static members of a class. They don't need instances to exist. As long as the class exists, the static members exist. So you can use static methods to perform tasks without needing to make an instance (for example data validation) and you can use static properties to hold values that need to be stored once only for the class. 

My idea is that folks can go from Jupiter, to static, to always here, to methods and properties and they'll have a handle on what it all means and how to use it. Which I think is better than a diagram.

Final Year Project Interim Demonstrations

The department is trying something new this year. Each of our Final Year project students is being asked to give an interim demonstration of their project to their second supervisor at around the project mid-point. The students see a lot of their first supervisor, but they don't usually see the second supervisor until later in the project, when they are involved in the final viva and the assessment.

This year I'm getting to see all the projects for which I'm second supervisor. I wasn't convinced at the start, what with the nightmare of fitting a whole new bunch of meetings into an already crowded diary, but I must admit it has been really useful. I've seen some really great work, and some that could be made great by a strong focus on the important elements.

When considering things like this I'm much more impressed by an "end to end" demonstration of a working system with "n" features than a half-way demonstration of a system with "n*2" features. If you are making a game, it should be playable all the way to the end, with a high score table and a chance to play again. If you are making a product you should be able to  run through an entire scenario of whatever transactional behaviours the product provides. If you are performing research you should have the theory, the things you are going to do to prove/disprove the theory and some outcomes to look at which drive the conclusions. And it is worth trimming the scope so that you can achieve this.  

Writers have this thing where they talk about "killing your favourite children" which means that they have to discard a great piece of text out because it doesn't actually add anything to the work. The text might be funny, or poignant or interesting - but if it doesn't fit the context it has to go.

During the meetings we were encouraging students to take a look at their projects and do something similar. This isn't to say that they should not get credit for work that doesn't end up in the finished deliverable. My advice is to write these up in the report and then document the process by which you decide to leave them out in order to focus on the core of the work. In fact, I reckon that getting a handle on your project and dropping features that will make you fail is actually strong evidence of real professional ability. And in real life you can always save these for version 2.0 anyway. 

The Magic of CallerMemberName

Oh my goodness. The things you find when you are searching for something else. While I was looking up some stuff on Model View View Model I came across a C# feature I've not seen before. It's called [CallerMemberName] and it is awesome. It has some  useful siblings too, which I'll get to in a moment. I'm dashing off a quick blog post about it now so that I can tell everyone, and also so I can remind myself how it works in the future.

CallerMemberName lives in the System.Runtime.CompilerServices namespace and it has one simple behaviour. It lets a method know the method or property it was called from. You use it as a parameter to the method, like so:

void Demo([CallerMemberName] string name = "")

The method Demo has a single parameter which is called name. All it does is print the name out. The parameter has a default value of "" and the strange [CallerMemberName] attribute thingy in front of it. When the method runs it prints the contents of  name. So, if we make a call to Demo from within another method - like this:

public void DoSomething()

- the program would print "DoSomething", because that is the name of the method that called Demo. It gets better. I can also do things like this:

private int aProperty = 0;

public int AProperty
        return aProperty;
        aProperty = value;

This time I'm calling Demo from within AProperty. And it prints "AProperty".  So far, so good.  Might be fun for code instrumentation. But why do I like it so much?

Answer, if you've not figured it out already, is that one of the more painful things about creating ViewModel classes for your applications is that when you set a property you have to call a method to tell the system that the value of that particular property has changed. And you have to give the method call the name of the property that has changed. As a string. If you get the name wrong (it has been known) a whole heap of nothing happens and your display is not updated properly. If you've done any MVVM in C# you'll be nodding around now.

If we use [CallerMemberName] we can get the name of the property being updated straight from the property itself, which means that we can make a generic notifier method that works for all the properties in the ViewModel class. No more errors caused by mistyping. There's a nice description of that part here

There are a couple of other "Caller" features you can use that work in exactly the same way, and might be fun to play with:


They are fairly self-explanatory. 

Great fun. 

Making Useful Software is Hard

Turns out that making useful software is surprisingly tricky. Take "Magic Marker", the program that we used last week to help out with the marking of the first year coursework. It was simple enough to write, it just finds the coursework from a archive downloaded from the university learning environment, sets up a spreadsheet for the marking process and then puts all the comments back into the correct format for upload. I made it last year and it worked fine. For me. 

This year I built it out a bit for use by five markers working in parallel. My plan was to slightly extend the program to merge back all the marked work. This turned out to be surprisingly tricky. Not because of the difficultly of the task, I had the code working in double quick time. The thing that caused the grief was that if you introduce more moving parts into a system the number of ways it can fail goes up exponentially.

This is something I've experienced before. It takes you ten minutes to code up the bit that does the work, and a day to cope with all the fiddly ways in which the program can go wrong. For example, at one point in the assessment process you have to copy the mark from the spreadsheet into the marking took. Of course I forgot to do this for a couple of folks and so my program got upset as a result. So I had to figure out how to mitigate this and then build it into the workflow. 

The good news is that having lots of students provides a great way to shake down the solution, and I now have a solution that will be useful going forwards. But this took a bit more coding than I expected. Remember, when you are writing code that the "Happy Path" will probably take you around 10-20% of the development time.  

When you are designing the workflow for a system you need to identify all the ways that it can go wrong and then specify what should happen in each. This is something that I tell everyone on the Systems Analysis course, and perhaps I should have followed my own advice a bit more at the start of this job. 

What is Assessment For?

At this time of year we do a lot of assessment of our students. This week I'm going to be spending the best part of four days in the lab with a bunch of my colleagues, pointing at bits of code written by students and asking "What does this do?". Great fun.

You might think that we do the assessment so that we can give the students grades. True enough, but to me the assessment is more important than that. We also want to have a framework in which we can talk to each student about the programs they have written, and how to make them better. The marking scheme provides lots of hooks we can use to hang discussions about good program design, documentation and testing. 

By the end of each marking session the student will have a number and hopefully they'll have learnt a bit more about software development. Which is kind of the plan. 

What makes a Bad Programmer?

I've been spending quite a bit of time with the First Year students this week. They're presently grappling with the "Space Cheese Mining" coursework which is a silly board game loosely based on Snakes and Ladders but with a few twists. And some cheese. 

Anyhoo, I was telling one student that I didn't allow First Years to tell me they were bad programmers. "That's my job" I said. The point I was going for is that one of the problems people have when learning to program is that they lack confidence in the code that they write. Sometimes they worry that they might not have found the "best" solution.

It turns out that some things are just hard to deal with, and require fiddly bits of code no matter how you approach them. So your code ends up looking a mess, and that's just the way it is. Snag is, when you are learning to program you don't necessarily get this, and you might worry that your program looks messy because you can't actually write code. So I always say that I'll be the judge of bad and good code, 'cos I've been writing programs for some time. 

We talked it through a while and then the student asked a really tough question "So, what makes a bad programmer then?" Ugh. Wasn't expecting that one. I didn't really have a ready answer. I muttered about bad coding style, not testing code, etc etc and that was that. 

Having thought about it some more though, I reckon I was wrong. I now think  a bad programmer is someone you don't want to work with.  They might write code that nobody can understand. They might refuse to test their solutions. They might refuse to believe that there is a problem with something they have written. They might not buy their round in the pub. They might get into fights with the customer. And they might enjoy telling you about bugs in your code rather too much.

Technical ability will get you so far in this business, but if you aren't good to work with this is going to hold you back in the long run.

Suiting Up Pays off

The "Black Godzilla" team in Three Thing Game made an awesome game. And they turned up at the Finalist Presentations fully suited and booted, and looking really sharp. Like winners in fact. I caught up with one of the team today and he told me that they had decided to dress properly for the event. 

I think this is a great idea. Way back when I was mentoring Imagine Cup Teams I had a habit of nipping down to Asda and picking up sets of matching shirts for the teams that I was looking after. This got a bit expensive when we had four teams in the UK finals one year, but it made a huge difference. For one thing, the students looked like proper teams.

If you're engaged in any kind of team work it is well worth giving some thought to this. It doesn't have to be expensive, just all get the same style T shirt or whatever. And the funny thing is, once you look like a team you start to behave more like a team too.