Pangram verdict · v3.3
We believe that this text is a mix of AI, AI-assisted, and human-written content.
AI likelihood · overall
MixedArticle text · 1,351 words · 8 segments analyzed
A process that doesn’t depend on individual brilliance 2026.09.28KO | ENSoftware and engineeringThe application of engineering to softwareExplaining intuition in engineering termsWhen an engineering approach is neededThe end of software engineeringPeople 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, they seem better at mathematics than a programmer. And somehow, their work seems more important than a developer’s. In fact, in some Canadian provinces, titles in computing 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 softwareFollowing 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 termsThis may sound a bit like ivory-tower thinking, so a concrete example might help.
One day, the operations team tells a programmer working on an e-commerce platform that the product detail pages are too slow and asks them to improve loading times. 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, query 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%.