Why software doesn’t “just work.”

•August 15, 2013 • Leave a Comment
Here are my two bytes on the matter: Computers are seemingly very simple; they take 1s and 0s, perform some mathematical functions, return the result and repeat. But computer software is very complicated these days. There are many different layers which software operates on (a kernel talks to the hardware, an operating system talks to a kernel, an application talks to the operating system, a user talks to the application), designed by many different people, used on many different pieces of hardware and communicate between each other over a network.
Apple like to say that their software “just works”, but every piece of software is prone to errors. Some errors are very visible (e.g. a computer crash, such as OS X kernel panics) and others are not (perhaps a piece of software seemingly works most of the time, but sometimes functions incorrectly, which both frustrates users and makes it very hard to diagnose). On top of that is the design of software, which you would typically regard Apple as a good designer because their products look clean, simple and intuitive, which they probably do more than most (sometimes too simple if you ask me), but sometimes it’s a design failure which causes a user’s problems, such as not being able to locate a function where the user would expect it to be. In that case a software engineer calls it a “user error“, because the software does exactly what it is supposed to do, but the user doesn’t understand how to use it. For some software the design should be so simple that anyone can use it intuitively, such as a calendar where it should be obvious how to flick through the months and insert a new entry, just like a real life calendar. For other software it’s just not possible to be simple, such as Logic Pro, where there are endless menus, endless options, and endless ways to combine things together, because you expect and need that kind of power and freedom with a professional piece of software. In real life you would have to fill a room with 1,000s of switches to simulate the various options the software provides to you, so it is merely a matter of learning how to use the software’s interface. Of course, if such a complex program has a bad interface, then you’re making it much harder than it needs to be to use an already-complex program.
Unlike cars, software isn’t something which average Joe can examine or fix, because the source code (the code used to build the software, kind of like a blueprint or schematic) is typically not available. Any person can open the bonnet of a car, find a broken spark plug and replace it using the right tool, but if you were to inspect a piece of software, it would just look like jibberish, no matter how much of an expert they are in software development. For this reason, if a piece of software doesn’t do what you want, typically you have to move on and find another piece of software. And if you cannot find a piece of software which does exactly what you want, then you’re out of luck unless you are capable of writing software yourself, or have the money to employ a team to make it for you. A lot of open-source software exists, where the source code for a piece of software is available to the public, meaning anyone can dive in and fix a problem or add new features. However, since the majority of computer users do not understand how a computer works, let alone have skills in software development, it’s not very beneficial to the public, except in that the software can typically be advanced and fixed much faster than closed-source software (with the added benefit of many people checking the code, meaning fewer errors are let through). In closed-source software, it may be the case that only a single person on Earth knows how some code works, and only a handful of people may have access to the code. Open-source software is also less invested in financially, since if you make a good product which people want, why not keep it to yourself and charge people money for it?
So, all software operates differently, unlike pens which all obey the laws of physics and have a standard design. All software operates in an unknown way, unlike pens which are simple enough that anyone can understand how they operate. Complex software will typically have problems which the developers didn’t notice, and the users certainly cannot do anything about. Interaction between software and physical hardware or networks like the Internet introduces even more opportunities for errors. Users who have no time to learn how to use software are error prone. Badly designed software wastes the user’s time and frustrates them.

Unity3D: Vector3 – magnitude vs sqrMagnitude

•May 2, 2013 • 1 Comment

The Unity Script Reference states that Vector3.sqrMagnitude is “much faster” than .magnitude, however it doesn’t say by how much. I use it for testing the distance between two objects to see if one is in range of the other (by subtracting one Transform’s position from the other, then finding the magnitude), and when you have many objects to test, it would be wise to use the fastest method. I did a couple of tests on my PC and smartphone and here are my results:

PC (Intel Core i5, 10 million executions per run per function, averaged result over 10 runs)

sqrMagnitude: 2853 ms. (96.13% of magnitude’s time)

magnitude: 2968 ms. (104.03% of sqrMagnitude’s time)


Android (Samsung Galaxy S II, 10 million executions per run per function, averaged result over 10 runs)

sqrMagnitude: 6155 ms. (77.11% of magnitude’s time)

magnitude: 7982 ms. (129.68% of sqrMagnitude’s time)

After averaging all the runs on PC the two results are very similar, although sqrMagnitude is definitively faster, albeit by only 4%. On my phone the numbers are much more dramatic, with a time saving of almost 23% when using sqrMagnitude instead of magnitude.

It’s unlikely that you will need to worry about this unless you are developing for mobile or you are using these functions over 10,000 times per frame on PC. If you are developing for mobile or you have any efficiency worries or drop in framerate and you use these functions 1,000s of times per frame or more, then it would be wise to use sqrMagnitude over magnitude. Of course, you will also have to change your comparison values to their square equivalents or you won’t get the same functionality.

Know your modifiers: Static

•May 1, 2013 • Leave a Comment

Here’s an example of a a class containing a couple of fields (class variables).

public class Player {
	public static float maxHealth = 100f;
	public float health = maxHealth;

The static modifier is useful for when you want a field or method to be identical to all instances of the class, or if the class you are making only ever needs one instance. A static field only exists once within a class, unlike instance fields which exist for each object you create.

In the example above, we are simulating players of a video game whom each have a health bar. I want all players to have a maximum health value of 100, so I have declared the field maxHealth which initialises to the value 100f and will never change. I also have the health field which can be changed by actions in the game. Of course, each player needs their own health variable so that different players can have different values of health, but each player does NOT need their own maxHealth variable, because it is not related to any one player instance. Because of this, we modify the field with the static modifier. This means that all Player instances will share the same maxHealth field, as it will only be created once.

The other effect of making a field static is that it can be accessed without creating any instances of the class. For example, the following statement would return the maxHealth value by accessing the class directly.


A static field also reduces the amount of memory required by the program, as there will only be one copy of the value.

Below is a graphical representation showing how static fields and methods only exist once within the class, whereas non-static or instance fields and methods exist per-instance and are separate to each other.



•April 11, 2008 • Leave a Comment

I plan on doing something creative soon, a one man project. I’m not yet sure what this will be, most likely related to games however (potentially a game itself.) I am also going to blog about it as I go along.

Stay tuned. 🙂

It’s raining

•December 16, 2006 • Leave a Comment

Typical weather for England at 2AM, but I love watching it.
I could spend forever looking outside my window covered from most of the rain. Good to get a bit wet as well. 🙂

Aside from that, there’s not long left until christmas!


•November 23, 2006 • 1 Comment

Yay, I have a wordpress blog! Go me!

Hello world!

•November 23, 2006 • 1 Comment

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!