This is a slightly altered version of the summary of a report I wrote for a company that attempted to explain to them why they should have a software engineer (a real one) on their staff, and why it would help their bottom line.
Reviewing and working with most legacy software typically leads to an observation that is hard to avoid: Software engineering is arguably the most important aspect of any software implementation activity.
Bright high school kids can write readable code, but they can’t create a message sequence chart, a good flowchart, a UML diagram, write a requirements document, or develop test procedures. A lot of older software developers, even some with many years of experience, can’t do those things, either. Without those types of engineering design artifacts in place to guide and evaluate the process, the coding effort is just an exercise in ad-hoc trial-and-error attempts to get something that sort of works as expected.
Although the two titles are often confused (mostly by well-meaning but ignorant HR people writing job descriptions), a programmer or software developer is not a software engineer. Developers write code according to requirements of some type, engineers do planning, analysis, requirements capture, and documentation, and sometimes write code as well. Experience has shown that the tasks that a software engineer performs are anathema to many software developers. Hence the lack of documentation, useful comments, diagrams, or any other significant signposts that could be used to navigate legacy software that is bound to occur when no one is keeping an eye on the big picture. Legacy code is often rife with signs that it was assembled ad-hoc from vague verbal directives by programmers and software developers, not planned out and orchestrated using software engineering practices.
Why is planning and design so important? Without software almost all modern technology, be it a personal computer, a spacecraft bound for Pluto, or a scientific instrument, is just an inert collection of plastic, metal, and silicon. Software is not something that can be treated as an afterthought, or something trivially created that is simply added to make things go. It is the soul of the machine. How the user will perceive a software-dependent product in terms of ease-of-use, reliability, and quality, is based on the experience they have when interacting with the software that runs the product. Anything that one might have learned about software development in their freshman year computer introduction classes is overshadowed by the realities of complexity, reliability, and end-user perception.
It doesn’t matter if the mechanisms are the most clever things ever devised, or how many patents are applicable to the product, if the software is buggy, unreliable, difficult to use, or amateurish, then the user will see the entire product in light of their experience with the software. Why not invest in the future and make software that will enhance the user experience? Good software engineering is an investment that will pay dividends in increased sales, enhanced market presence, reduced maintenance and modification costs, and a solid reputation for years after the initial work is completed.
As you can probably surmise, I am not inclined to confer the title of software engineer on someone just because that’s how HR listed the job position. Do you think there’s a definite difference? Does up-front engineering work result in a better final product? Or, perhaps, as one righteously indignant programmer once told me: “Software engineers are just bozos who can’t code.” What do you think?