Main menu:

Site search


May 2024
« Apr    



Some basic facts about software engineering

I wrote my first programme thanks to my mum asking a basic question having typed out a load of programmes from books so we could all learn how to do computer programming – “what do you want to do next?”.

That was when I really learnt about testing and how to prove something worked. As a kid, these early explorations lead to me wanting to study maths – a large part of which is proving things work as you think they do – and computer science.

Testing your own code is hard. Really hard. Because if you’re not careful, you test it the way you wrote it – as an expert user of that piece of software, you test the happy path.

But my early programming experiments lead me to learn about how numbers really worked, about seeing edge conditions. The code was very naive, very basic. But as a result, liable to end up in trouble.

Of course, as a professional coder, this is not what you do when writing code for selling. You defend the code, you use exception handling to ensure the edge cases do not stop your code from running and get other pieces of code to verify what you’ve done. It’s taken 40 odd years to get to the stage I am now. And largely, I have enjoyed the journey: especially the moment when an end user gets the tool that helps them to achieve more, faster and more effectively.

At the moment I am examining this as part of my day job, how can we test without writing a single piece of code to run the tests – which sounds odd when you consider we’re all looking at automation. How can you automate without doing anything?

This is where the mathematician part of my university education kicks in. In maths we have different ways of proving things. Induction is all about proving a statement is true for 0, and it’s true for 1 – can we say it is true for x+1 where x is any number. We can do this in the reverse order too, if true for x is it true for x-1?

But we can also prove by contradiction. This is all about saying something isn’t true and then proving that isn’t so. That’s really what I am looking at doing at work – I’m testing by getting other tools to analyse various pieces of software I’m writing and saying that the pieces must work if no faults are found by the other tools. QED, so to speak.

Write a comment