(Practice has changed my view on the subject since I wrote this ranty and simplistic post. As of 2014, I still agree with the essence of this article, but I’m planning on creating a follow-up that better addresses the complexity of this subject.)
Tired of the indeliberate usage of the term “software engineering”, where “software developer” and “software engineer” seem to be exchangeable, I’m writing this article to explain what I think Software Engineering really is.
But first, let’s remember some basic terminology:
- Anyone who can create a program in at least one programming language, regardless of the use of a systematic approach (if any).
- Software developer
- A software developer is a programmer who doesn’t only care about about simply writing code, but also cares about (although may not be directly involved in) the requirement analysis, the functional specification, the design, the testing, the deployment and the maintenance of the software product they work on. Disciplined software developers usually follow a software development methodology, like XP.
- According to the Wikipedia (bolds are mine): “Engineering is the discipline and profession of applying technical and scientific knowledge and utilizing natural laws and physical resources in order to design and implement materials, structures, machines, devices, systems, and processes that safely realize a desired objective and meet specified criteria.”
Both programmers and software developers qualify the software progress. They can’t often meet deadlines nor track process because they don’t know for sure where they are nor where they should be. Qualification is subjective and absolutely imprecise, so you can only have subjective and imprecise answers to precise questions like “when it’s going to be ready?” (to which the most common answers are “soon” or “when it’s ready” in the freedomare world).
When you travel by car, what can you do to find how far you’re from the destination and how much time is left? You have to measure. If you find a sign that states that you’re 20Kms away from your destination and you measure the current car’s speed (well, your car does so for you) and it turns out to be 60Km/hour, then you’ll realize that if you keep the speed you’ll arrive in 20 minutes. If you don’t measure, you can’t tell if you’re on time and you can’t even avoid getting late next time (to improve, you need to know the previous measures!).
If you quantify, you will find the real status of a given process and whether you’ll reach your goals within the desired parameters (time, money, etc.). If you quantified and analyzed such measures, you will be able to execute the right corrections in order to improve the process and thus reach the goals within the desired parameters, or at least reduce the difference between the desired parameters and the final results (this is, reduce risk). And that’s not specific to software.
So, the difference between a disciplined software developer and a software engineer, is that the former qualifies and the later quantifies. In a software engineering project, when a process is going wrong, it’s found (the sooner or later) thanks to software metrics (or “software measurements”) and the appropriate steps are taken to reduce risk. In a software development project, the process is not measured and software product is delivered out of at least one parameter (over-budget, with less features, after the deadline, etc.).
I don’t think you need a diploma that says you’re a software engineer (or hold a position ending by “Software Engineer” in a organization) to call yourself “software engineer”, unless required by local law. But you need to be a disciplined software developer who measures the software process and make decisions based on an objective analysis of the relevant measures.
There are good resources out there to learn more about software measurement. The one I strongly recommend is “Software Measurement” by Christof Ebert and Reiner Dumke (ISBN: 978-3-540-71648-8). This book is a great introduction to software measurement and covers the four kinds of software metrics (project, process, product and people metrics). I think it’s a must-read for anyone involved in software processes and wants to improve continuously (which can only be achieved by measuring!).
But there are also good resources on the Web, like the ones listed below. Unfortunately, I couldn’t find something like the book above, but online.