Software Engineering for Humans #1
I don’t mean to gas you up or anything, but you’re probably one of our very first readers. Welcome.
This will be the first in a series in which I, explain to you, dear reader, what Software Engineering means. A topic which you seem to be pretty interested in since you managed to make it to our very humble corner of the internet.
In this article, I’m going to start you off with the very bare bones of what Software Engineering really is. Buckle up, this will probably be a short-read… or a long one depending on your attention span, really.
What the hell is Software?
No need to feel insulted, I know you probably have a vague idea of what a software is supposed to be, hell, you’re viewing this on one right now, but let me explain the concept to you a bit more intricately.
The definition of the word “Software” according to the Cambridge dictionary is the following:
“The instructions that control what a computer does.”
Pretty straight-forward, huh? You basically feed a computer a bunch of code to achieve a certain task and voila! Task achieved.
“Software” is basically a fancy way of saying computer “program”, and there isn’t just one type of it out there:
System Software
This is the Alpha of all software. These allow you to interact with the complicated block of electrical circuits you have in your hand or in front of you right now.
Application Software
These are the basic software used to accomplish a particular action or task. You’re viewing this on one right now!
Utility Software
They mostly work to feed the most basic needs of your Operating System, and sometimes your needs as well.
The actual term ‘software’ wasn’t used until the late 1950s. Many of the early pieces of software weren’t available commercially; instead, the people who ACTUALLY used computers cough scientists cough often had to write their own software. This did have some advantages: the software was tailored to their own needs, and the user understood exactly what the hell the software was supposed to be doing. However, this did end up having some issues. Every business or lab had to have someone capable of programming the computer, and the software often couldn’t be traded to others because it was created for one specific computer system. How tedious.
When computers became small enough to be sold to normal individuals, software became much more prevalent, and since no sane person would just decide to sit down and program their entire computer system themselves, the operating system was created.
Now let’s add “Engineering” to the equation, which complicates things a little
IEEE – Institute of Electrical and Electronics Engineers – defines Software Engineering as:
“The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.”
During the 1960s, a crisis occurred. Developers discovered that building large, complicated software is really damn hard, and actually very dangerous. The issue stemmed from their inability to apply the same techniques they used to build small software systems to the development of larger and more complicated systems, and this group of techniques – or approach was named “Code and Fix”.
Code-and-fix development occurs when software engineers come together with a vague set of requirements and immediately think they can start producing some sick software, fixing it, and changing it until the correct product appears. This is disastrous for large software for a few reasons, among them:
- There is no way to estimate timescales or budgets.
- There is no assessment of possible risks and design flaws: you may come close to a finished product only to find insurmountable technical problems which sets the whole project back.
And this leads to:
- Unfinished systems
- Missed deadlines
- Exceeded budgets
- a system that does not do what it’s meant to do
- a system that works but is an absolute nightmare to navigate
- a system difficult to modify to meet changes in organizational needs and practices
- a loss of trust from users
Now, obviously, this all occurred due to a lack of discipline and organization among the developers, and thus, Software Engineering was born. Hallelujah.
So, basically, a Software Engineer’s job is to create a product that is reliable, efficient, and effective at what it does, and that product (the software) is usually judged by how easy and how impressive the end-user (you) finds it.
Clearly, dear reader, you’ve recognized by now that Software Engineering is actually kinda really important. You can’t just sit down, write code, and expect everything to come out smoothly without having some sort of structure to what you’re doing, or else you’d end up spinning around yourself wondering how it all got so wrong.
What is that structure like, you may ask? Well, you’re in luck! Because that’s what we’ll be answering next time, you better stay tuned for that one, it’s a doozy.