Software Engineering is a broad term that encapsulates a lot. We can begin by taking the two words inversely: Engineering software - taking a practical, methodical, and systematic approach to building software. There is a Body of Knowledge (SWEBOK) that categorizes the depth of knowledge expected of a software engineer, including requirements, design, tests, maintenance, configuration management, processes, and more.
A programmer at its core programs, or codes; however, a software engineers goes beyond that. Analogically from a mathematical stance, a programmer is like a subset of the bigger software engineer set. Imagine you are in charge of delivering some sort of software product to a client: a software engineer is involved in the whole development from beginning its design to the end of its life cycle to ensuring the software is delivered to the client, and even beyond that, to its maintenance.
To translate it into a simple schema:
Software Engineer prescribes the design of a component of a software => Programmer implements the design => Software Engineer integrates the component back into the software and the overall cycle of the software's development.
There are many more intricacies to an actual life cycle of a software development process, nonetheless the above sufficiently illustrates the difference between a programmer and a software engineer.
To continue the aforementioned idea of the depth software engineering, some of the fundamental software engineering concepts covered in ICS 314 Software Engineering include:
In my technical essay, “Standards on Coding Standards”, I discuss the importance of coding standards. Indeed, once again! Standards are high and imperative for the software engineer, coding especially, as it is the core of what makes the software. Why do we have standards? It is to communicate effectively and efficiently. Just as how the English language we speak and you are currently reading enables us to communicate (or ever understand each other to begin with), coding standards are the language of the software engineer (or programmer). 你能想像我如果用國語寫這篇文章嗎?你能看懂嗎?(Can you imagine if I wrote this essay in Mandarin? Would you be able to understand it?)それとも、日本語を使ったら?(Or if I used Japanese?). Unless you know the language already, we would not have been able to communicate because it was not agreed upon for us to communicate with such languages. Coding standards are similar. They are in place because they enable to team involved to communicate properly, and sometimes, for the computers to even communicate at all!
Takeaway: have some standards :)
How does a project come together? How do you manage a project? Manage the team? Imagine you dive deep into starting a project without much overarching consideration of the project as a whole. You start coding; your peers start coding. You all integration the codes together, and – it doesn’t work… You have all coded under the same programs, same language, and the same coding standards, but you are seeing the direct effect of failing to manage the project.
Software development is a complex process, and processes is all it is about. To grow the software process, you start with a set of work practices, tools, and techniques - defining how you are going to begin your process. You then develop your software - work the process - and find out your deficiencies in the process, and you improve it, and work the process again. This cycle can be shaped into various models, such as the Waterfall model, Spiral model, CMM, and Agile development, or Agile Project Management.
The first three aforementioned methods are non-agile, and what makes the last “agile” is a set of practices, particularly extreme programming (XP). It includes:
Agile Project Management are lightweight, suitable for teams working on smaller projects that can deliver a product in a short amount of time and in various presentable stages. In ICS 314, Issue Driven Project Management (IDPM) was used to fulfill the final project requirement to develop the Manoa Marketplace App. It centers its management around Github, using ‘projects’ as milestones to meet weekly, and ‘issues’ as small tasks to complete daily.
Why do we need software engineers? Software engineering comes from a long history of massive failures, projects that were undelivered, costing billions of dollars. Learning from history, milestones were achieved to improvement the software engineering process itself, through SWEBOK, ISO standards, the unified process workflow, and much more.
Everything is a process, and it is the process that drives the path it takes to reach the end goal. WHat can be learned from software engineering practices can very much be applicable to other disciplines and toward approaching life in general.