It has been said that software development is more art than engineering but, like most technically oriented professions, it is actually a bit of both. The art aspect is most obvious in today’s sleek websites and colorful mobile apps but there is more subtle art behind those user interfaces.
The same way a sculptor knows how to approach a raw block of marble and what tools and techniques will produce the right outcome, an artful developer knows their tools (languages, IDEs, algorithms) and how best to use them to fulfill the specifications and requirements of a project.
There is art in programming. To a developer, well written code is not unlike a well written story. Notice, however, that I used the term ‘artful developer’. Creating beautifully presented software with the flavor of the month programming language isn’t necessarily engineering and that may become obvious once a user begins to work with that software. No, it’s the second part of the statement, the part about ‘specifications and requirements’ that begins to shine some light on what makes a software programmer also a software engineer.
A software engineer is a programmer that recognizes and applies common processes and best practices to a given project based on the specifications and requirements provided by the project owner.
The simplicity of that statement is deceiving and the explanation of it is deeper than I will go into at this time, but I’ll break it into manageable pieces and we may explore it further at another time.
“A software engineer is a programmer…” A software engineer with little or no practical development experience is likely to cause more harm than good. A person trained in the principles of software engineering but lacking real knowledge of language characteristics, algorithm implementations and common environmental limitation will have a difficult time creating accurate estimates, realistic design decisions and feasible deployment and maintenance processes.
“…applies common processes and best practices…” This is a tightly wrapped statement. The exact definition varies based on language and environment and the importance of identifying the right language and tools for a project is tied to the statement as well. There is no “best” language. There is a right language for the job. There are also some generally accepted best practices that apply regardless of language (source control, Test Driven Development (TDD), the DRY principle), but even these may be project dependent. The important takeaway is that a software engineer can identify, from specification, the initial development processes and procedures that will be best suited to the project.
“…based on specification and requirements… .” The bane of any sufficiently large software project is the specification and requirements that are intended to drive development. Specifications and requirements are the marching orders of a project and are often times incomplete, ever changing, or overlooked entirely. The software engineer understands the importance of these documents and will ensure that they are held to the same standard as the final deliverable. There are codified common specification and requirement frameworks available (MIL-STD-498, IEEE 12207, ISO/IEC 12207) and they can be a great starting point for a new project or a company standard (Duotech uses MIL-STD-498). A software engineer should work with the project owners and stakeholders to identify and realize the specifications and requirements of a project prior to making any realistic estimates or implementation decisions.
Software engineering lacks the history of other engineering disciplines and, as such, is still very much defining itself. Few fields of study are moving as quickly as computing and standardizing and codifying in an ever changing environment is difficult. This situation often leads to the perception that the field lacks true discipline. That perception couldn’t be farther from the truth and the software engineer should be constantly evolving with the industry.
