What makes software development engineering

A process that doesn’t depend on individual brilliance 2026.09.28

KO | EN

People who make software go by many names. Developer is the most common, while programmer sounds neutral and a little traditional. Coder literally means someone who writes code, but it can also be used disparagingly, suggesting someone who takes a passive role, writing code without participating in the many other activities involved in software development. At the other end of the spectrum is the software engineer.

The title software engineer has a rather different feel. Somehow, a software engineer seems more professional than a coder. For some reason, you expect them to be better at mathematics than a programmer and to do more important work than a developer. In fact, in some Canadian provinces, computing-related titles such as “software engineer,” “computer engineer,” and others containing “engineer” are, in principle, reserved for people licensed as engineers by the provincial engineering regulator. Many people assume that someone with the title of engineer holds a recognized professional qualification or license.

All of this is about the subjective impression the title engineer gives us. But if many people share that impression, it is worth asking why. If software development were self-evidently a form of engineering, there would be nothing special about the title software engineer in the first place. Where does this impression come from? Why does software engineering feel different from mechanical, electrical, or civil engineering? And what makes software development engineering?

Software and engineering

NATO Software Engineering Conference (Robert McClure, Brian Randell)

There is no single definition of engineering, but it can generally be described as a field that systematically solves problems by applying mathematical and scientific knowledge within various constraints to meet human needs. UNESCO^[1] and the US National Academies^[2] offer the following definitions of engineering.

Engineering is the field of practice, profession and art that relates to the development, acquisition and application of technical scientific and mathematical knowledge. It is about the understanding, design, development, invention, innovation and the use of materials, machines, structures, systems and processes for specific purposes.

Engineering is both a knowledge of the creation and design of human-made products and processes and a problem-solving method called design under constraint.

Attempts to give software development the same systematic foundations as other engineering disciplines date back to the early days of computing. The 1968 NATO Software Engineering Conference^[3] is often regarded as the starting point of software engineering. A recurring concern at this conference, held in Germany, was that software was growing more complex as its scale and importance increased rapidly. This became known as the software crisis. The participants reached no consensus, but they seem to have broadly shared the view that software development, still a young field, needed methods and structures comparable to those of established engineering disciplines to address its immediate problems. The editors of the conference report wrote this about the phrase software engineering.

The phrase ‘software engineering’ was deliberately chosen as being provocative, in implying the need for software manufacture to be based on the types of theoretical foundations and practical disciplines, that are traditional in the established branches of engineering.

Thomas Haigh, meanwhile, sees greater significance in a debate that took place before the conference within IFIP Working Group 2.1, which was developing a successor to ALGOL 60^[4]. The prevailing view in the group was that it should be possible to express complex programs by combining a small number of basic concepts. This philosophy strongly influenced the ALGOL 68 draft. Those in the group who cared more about making complex programs reliable than about how to express them opposed the direction ALGOL 68 was taking. The opponents of ALGOL 68 were at the center of the NATO Software Engineering Conference. They believed software development needed to become a more rigorous and controllable activity. One of them, Edsger Dijkstra, treated programming as a form of applied mathematics and later invoked the software crisis again in arguing for structured programming.

We should bear in mind how far removed these debates about software engineering were from the work of application programmers. Most conference participants were researchers, while most applications at the time were financial, accounting, and personnel software written in COBOL for business data processing. The concept of software engineering discussed in 1968 therefore cannot account for the software industry as a whole at the time. Yet programmers trained today are influenced indirectly, and sometimes directly, by the ALGOL 68 debate and the NATO Software Engineering Conference. This is true if you have ever been told to avoid goto when programming in C, encountered subjects such as object-oriented or functional programming, or even just used modern programming tools.

The application of engineering to software

Following decades of efforts to establish software development as an engineering discipline, the Software Engineering Body of Knowledge (SWEBOK)^[5] uses the following definitions of ‘engineering’ and ‘software engineering.’

The Institute of Electrical and Electronics Engineers (IEEE) defines engineering as “the application of a systematic, disciplined, quantifiable approach to structures, machines, products, systems or processes”. (…) software engineering is defined as “the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.”

According to this definition, what makes software development engineering is the application of an engineering approach to software development. An engineering approach is a process in which an engineer chooses one of several feasible solutions to a problem according to certain criteria, implements it, and monitors the results. This process need not be sequential, but it must be iterative. In fact, an engineering approach is inherently iterative. Knowledge acquired at any stage may bear on an earlier stage, naturally prompting another iteration. Engineering decisions rest on estimates, so the quality of a decision depends on the quality of the estimates. Engineers must therefore compare estimates against actual results to create a feedback loop for estimation. Understanding what causes the gap between estimates and actual results allows them to refine their estimation techniques and make more accurate estimates in the future. This, in turn, allows them to keep making better decisions.

Explaining intuition in engineering terms

This may sound a bit like ivory-tower thinking, so a concrete example might help. One day, a programmer working on an e-commerce service receives a request from the operations team to improve the slow-loading product detail pages. A programmer who knows the system well might instinctively think of a solution on hearing that pages load slowly. This does not necessarily lead to a bad decision. But it is hard to explain why that decision is better justified than the alternatives, how much performance must improve to count as a success, or how much difference it will actually make to users.

An engineering approach begins with an accurate understanding of the actual problem. “Too slow” can mean many things, so the first step is to measure the performance of the product detail pages that need improvement. Recent metrics show an FCP p75 of 2,700ms for these pages. The recommended FCP p75 for a good user experience is 1,800ms or less^[6], making that a reasonable target. The programmer analyzes traces and finds that the SSR server spends a substantial portion of its rendering time waiting for the product detail API to respond. The product detail API has a p95 latency of 1,000ms, and slow requests spend 800ms waiting for database read queries. The problem can now be redefined from “pages load slowly” to “database queries are a latency bottleneck in read-heavy product lookups.”

There are several solutions to this problem. The programmer could introduce an in-memory cache layer, improve queries or indexes, direct queries to a read replica, or render entire pages statically and serve them through a CDN. Each solution has its own strengths, weaknesses, and tradeoffs. What matters is not rushing to conclude that the first solution that comes to mind is the right one. Traffic analysis shows that the most popular 5% of products account for about 90% of lookup requests, and cache TTL simulations suggest that introducing Redis could yield a cache hit rate of over 95%. Redis reads are known to take a few milliseconds, so a cache hit should bring latency down to around 200ms.

After comparing the alternatives, the programmer decides that building an in-memory cache layer with Redis would be the most effective solution. After Redis is introduced, the metrics show a cache hit rate of 65%, API p95 latency of 850ms, and FCP p75 of 2,000ms. These figures show a modest improvement. Investigating why the actual results differ from the estimates reveals that the product information depends on personalized data, making the cache key cardinality higher than expected. The programmer redesigns the caching strategy to store static product information in a global cache and fetch personalized data separately. This brings the cache hit rate to 97%, API p95 latency to 200ms, and FCP p75 to 1,400ms. This entire process follows an engineering approach, from measuring the problem and comparing possible solutions to estimating results and making improvements by comparing actual results against the estimates.

When an engineering approach is needed

Seen this way, software development clearly has an engineering aspect. The reason it still feels different from other engineering disciplines may be that it is possible to make software that works reasonably well in ways that do not meet the definition of engineering. Programmers can design without a systematic approach, write code without discipline, and produce software through a process that cannot be quantified.

Because working software can be produced regardless of the development process, an engineering approach is easily overlooked in practice. Software development has changed dramatically in a short time. Even the fundamentals of computer science, as we commonly call them, change far faster than the laws of nature on which other engineering disciplines rest. Many software development organizations have consequently focused on speed rather than following sound principles. As a result, software quality is all too easily treated as a secondary concern, despite how important software is and how serious its failures can be. Software is easy to change, as the “soft” in its name suggests, and providers may think that this justifies poor quality. For users, though, working with unreliable software is deeply unpleasant and can sometimes be dangerous.

There are other ways of looking at software development^[7]. Peter Naur argued that the real goal of programming was to build a theory in the programmer’s mind rather than to produce the artifact we call a program^[8]. Drawing on Gilbert Ryle, Naur used ‘theory’ to describe the knowledge and understanding formed in a programmer’s mind. A program expresses a mental construct that exists within the programmer, so information is inevitably lost when that theory is put into text. Losing the programmer therefore amounts to losing the program. Sherry Turkle and Seymour Papert called programmers who first make working software and then repeatedly modify and observe it bricoleurs^[9], and examined their way of programming^[10]. They argued that programmers could produce high-quality software by interacting with working software, rather than planning its entire structure in advance and breaking it down for implementation. Software gardening, in turn, treats software as a living organism and accepts its unpredictability. From this perspective, programmers are professionals who carefully tend the changing garden of software, guided by intuition and a sense of ownership.

Despite these different perspectives on software development, software development organizations still need an engineering approach. It cannot guarantee perfect software, but it can at least raise the minimum level of quality. Experienced programmers who have built theories in their minds cannot stay with an organization forever. Nor can every programmer be a bricoleur with exceptional intuition or a gardener with a strong sense of ownership of the product. An organization must produce software of consistently high quality despite differences in individual ability. The strength of an engineering approach is that even people with less natural talent can improve their chances of making good decisions by following a well-designed, systematic process. We do not need to approach every problem as an engineering problem. But when a problem has several possible solutions rather than a single right answer, applying an engineering approach to comparing tradeoffs, choosing a solution, and implementing it gives us reason to expect better results. An engineering approach becomes necessary the moment a software development organization must repeatedly produce reliable results without depending on individual genius.

What qualifies software development as engineering has nothing to do with the difficulty of the problem or the engineer’s credentials. Applying an engineering approach to software development is what makes it engineering. To solve problems, engineers make estimates, run experiments, take measurements, reproduce results, make improvements, and repeat the process. And we call the people who build software this way to solve problems software engineers.

The end of software engineering

Some sixty years after the first efforts to apply an engineering approach to software development, software engineering is beset by predictions of its demise. The argument is that, because of artificial intelligence, traditional software engineering approaches can no longer offer programmers practical help. If artificial intelligence here means LLMs, software engineering probably will not come to an end so easily. What these predictions really foretell is the end of the human software engineer.

For now, there are still meaningful benefits when human programmers take the lead in applying an engineering approach to software development. The first reason is that humans have to give AI context about the environment, including technical constraints, along with specific requirements. Give AI abstract business requirements, and it produces abstract results. After spending a long time wrestling with AI to refine an output that does not handle edge cases properly, you eventually realize that code is the clearest specification of business requirements. The second reason is that AI output varies in quality and is not reliable enough^[11]. The limitations are particularly apparent in brownfield systems, where human software engineers must intervene to measure and verify whether the output meets the requirements and constraints. For these reasons, human-led software engineering still provides a harness that guides both humans and AI toward consistently producing better software in practice.

In times of transition, anyone can make a plausible prediction. Perhaps AI will one day identify real-world constraints and define requirements on its own, producing black-box software that solves problems perfectly. Ben Shneiderman described AI systems that achieve greater automation while giving humans more control as Reliable, Safe & Trustworthy (RST) systems^[12]. If we focus only on automating software development and eventually software is made without human control, if no human bears responsibility for that software, and if we secretly wish for such software now, the prediction of our demise will become a self-fulfilling prophecy. At least for now, software engineers can decide their own future.