Apophis is a bit bigger than we thought…

Why is this barely making the news?

There is a big space rock called Apophis, and this asteroid is, right NOW (as I type this!), passing the Earth at a few million kilometers. As it does so, it is currently rated a 0 out of 10 on the Torino risk scale [0 is “bleh whatever”, 10 is “help! help! we’re all going to dieeeeeeeee!”] — but was once the highest rated asteroid _ever_ on there, at a rating of 4/10.

Today, there’s no risk of a collision — it’s a safe distance. However, it’ll be back in 2029. Again, in 2029 there’s not much risk of a collision, but it will be passing much closer — so close that it’ll enter the gravity well of our planet and probably change course slightly. Depending on how this goes, it may return in 2036, with a bang, literally. As in “crash bang wallop”. Continue reading

Software Motivational Pictures

Software development is a chore, particularly when writing a large piece of software. It’s very hard to avoid it turning into VampireWare — software that never sees the light of day, but drains the life out of anyone who works on it.

There are several things developers can do to avoid software becoming VampireWare, but a key one is getting the design right. Why? Because software changes – requirements change, interfaces change, users change, developers change.

Sticking to a good set of principles is necessary to ensure your software can survive the changes that happen around it. Derick Baily produced some motivational pictures and released them under the CC-BY-SA license.

I’ve reproduced the pictures below, however I have messed around with the colours to make them more “printer friendly”. Feel free to use the pictures under the same CC-BY-SA license I linked above. Continue reading

Programming Reference Guides

Like any good programmer, I surround myself with articles about programming. If I had the space (and toner) I would probably print off a sizable number.

But there’s a few that I couldn’t do without: a network layout diagram, a data model for my game mappings, some product management mnemonics, SOLID development pictures, some SCRUM diagrams and various other pieces of paper.

Some of these you’ll find elsewhere on this web-site. (Others I haven’t produced myself, so you won’t find those here…).

But here are a couple of programming references I keep to hand. Feel free to print them and use them for individual use (i.e., print them for yourself, but don’t go handing them out to others).

Download: ASCII Table (this includes hex and binary conversions)

Download: C and C++ Operator Precedence Table (this includes associativity and stylistic notes)

User Stories: should be SPACED OUT and PREACH them.

Okay, well as anyone who has worked in the software industry knows, A User Requirements Document is, by far, the most important document to get right.

It’s also the hardest document to get right, because requirements are often fluid and changing based on the customer’s mood swinging, or just the air pressure outside, the number of shooting stars that were visible yesterday evening, or any other factors — very few of which are under the control of the development teams.

There’s plenty of documentation for writing good User Requirements; one of the best I’ve seen is available from IBM [1]. However I’ve seen very few that are directly applicable to the “user story” methodology common to SCRUM / Agile projects. Continue reading