Developer, Engineer, or Architect?
Defining the differences between disciplines
By Andrew Anguelo
Back in the day, those who wrote software applications in the business space were called programmers. It was simple to understand what the work was at a particular level. For instance, a Programmer III was more experienced than a Programmer I. But over time, the title evolved to Programmer Analysts I, II, or III. Today we have software developers, engineers, and fairly recently, the new title of architect. A frustrating phenomena occurring around these titles is that developer and engineer are being used interchangeably, although they are distinct disciplines. In my opinion, the role of software architect has evolved as a result of interchanging developer and engineer titles to segregate specific skills a software engineer typically performs during the systems engineering process.
The IEEE Computer Society defines software engineering in the 2004 Software Engineering Body of Knowledge (SWEBOK) as:
(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
(2) The study of approaches as in (1).
Of most importance in distinguishing engineering from development in this definition are the words “systemic, disciplined, quantifiable,” which derive from core engineering principles based on science. In other engineering fields, application of a particular type of science within a field makes it engineering. For example, the science of physics is applied in the disciplines of structural and mechanical engineering. In software, it’s the application of computer sciences that makes up software engineering. This is what “the application of engineering to software” means in the definition. Note the word “development” found in this definition--it simply characterizes the iterative nature of, or phases necessary in, creating a software product. An overall way to look at engineering, regardless of discipline, is that there’s no guessing. Your work is accomplished with knowledge and intent.
Software architect is one of those new titles we see today in the corporate space ? a symbolic renaming of systems engineering skills. Once again, we look at the IEEE Computer Society definition of systems engineering from the 2004 SWEBOK:
“Systems engineering is an interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: operations performance, test, manufacturing, cost and schedule, training and support and disposal.”
This definition establishes that systems engineering is an aspect--“interdisciplinary”-- of software engineering. It’s the big picture of a software project from an engineering perspective. In today’s corporate nomenclature, a software architect is responsible for ensuring that complete consideration of such aspects as requirements, designs, topology, hardware, cost, schedules, and training of a project are encompassed in the end result.
When the Internet began taking hold during the dot-com boom, there was a shift in thinking around corporate software. Not only were desktop applications taking second place to Web-based products, big software companies began creating “development tools” and the term IDE (which stands for integrated development environment) became status quo. During that period, business executives were hot for the next best shiny technology object and pushed hard for fast development cycles. Loosely conceived ideas and requirements, ridiculously short timelines, and an intolerance for planning and documentation were common characteristics of projects during that time. (Sounds like a certain methodology, but that’s a subject for another article). In and around that Web culture was born the developer role that maintains those same characteristics to this day.
In short, development and engineering are based on opposite tenets. Engineering is scientific, quantified, and disciplined, whereas development is random, not based on metrics, and stays away from engineering discipline. In some businesses, hiring managers and HR departments create an incorrect context when they give a software developer the title of software engineer. This is what causes confusion.
A consideration for the industry
The incorrect use of software worker titles in corporate spaces has caused widespread confusion. As a result, it’s currently difficult to associate a software-related title to a specific job role. For hiring managers and HR recruiters, consider this: If you’re looking for skills that describe engineering, don’t post a job request for a developer. Similarly, if you don’t need engineering skills, then don’t post a job request for an engineer.
There are legitimate roles for development and engineering alike. Not all projects in the corporate space require an engineering skill set, and conversely, some projects need and should be engineered. There’s even room for new titles for old disciplines, so who knows what the next nomenclatures will be. Perhaps we should be called software astronauts, since every day on the job is an exploration into the unknown.
The point is, regardless of title, the role of a software engineer is what it’s always been: systematic, disciplined, and quantifiable. And it shouldn’t be confused with the role of a developer or any deviation from fundamental engineering practices that may arise in the future. CW (18 February, 2009)
Andrew Anguelo has worked for an array of small and Fortune 500 companies during more than two decades in software engineering. Today he owns a number of diverse businesses and is an active software architect of business and finance systems.