Two people see the final place in an imaginary workshop. Each presses Book. Each receives a reassuring animation. The organiser later finds two confirmations for one place.
No screen had to look broken for the system to fail. The failure lay in the relationship between a request, a shared record and the promise made to the user.
Software engineering is the discipline of turning a human need into dependable software behaviour, then preserving that behaviour while the software and its environment change. Writing code is part of the work. Requirements, architecture, data, testing, security, accessibility, deployment, operation and maintenance determine whether the code actually serves its purpose.
The IEEE Computer Society’s Software Engineering Body of Knowledge treats the discipline as a connected set of knowledge areas rather than a programming-language contest. Its published overview includes requirements, architecture, construction, testing, operations, security and professional practice. Source: IEEE Computer Society, SWEBOK.
This guide follows one fictional booking service from intention to verified operation. Its examples are original and educational. They are not a production payment system, a security assessment or a claim that a particular technology will satisfy every organisation’s requirements.
Reading routes: enter through the child-friendly explanation, investigate requirements and state, follow the last-place problem, explore testing and release, then use the reliability calculations and learning workshop.
Explain software engineering to a child: make the promise true, not just the picture
Imagine a library programme that lets pupils borrow books. A picture of a green tick is not enough. The programme must know which book is available, who borrowed it and whether it has been returned.
Now imagine two pupils trying to borrow the same copy. The programme needs a rule that works even when both requests arrive almost together. It must also remember the result after the screen closes.
A software engineer asks what the programme should do, builds a clear representation of that job and checks what happens in ordinary and unusual situations. What happens when the internet connection stops? What happens when someone presses the button twice? How does a pupil who cannot use a mouse complete the task?
The goal is not to make a computer appear clever. It is to make a useful promise remain true. A good programme also explains its state honestly: completed, still processing, not permitted or not yet known.
Part I: Before code, establish the reader’s and operator’s job
1. A request is not yet a requirement
“Build a booking website” names an object but leaves its behaviour unclear. Our fictional organiser needs to allocate workshop places, prevent overbooking, communicate outcomes and handle cancellations. The user needs to know whether a place is actually theirs.
Translate these needs into testable statements. A confirmed reservation must refer to an identifiable workshop and participant. The number of occupied places must not exceed the allowed capacity. A cancellation must have a defined effect on availability. A failed notification must not silently cancel a valid reservation.
These statements are more useful than a list of screens because they express the relationships the software must preserve. The same requirements could be implemented through different interfaces or architectures.
The SWEBOK topic map distinguishes functional requirements, quality requirements and technology constraints. Those categories help keep the required behaviour separate from a premature choice of tool. Source: SWEBOK topics.
2. Functional success and quality of service are different promises
A service can eventually produce the correct booking while taking so long that the user gives up and repeats the request. It can respond quickly while returning the wrong result. Correctness, response time and availability therefore need separate definitions.
For our example, define which action counts as success. Does success mean that the browser displayed a message, that a reservation was stored or that a confirmation email arrived? These are different events, and the system may reach them at different times.
A useful brief also names the operating conditions. Expected demand, relevant devices, language needs and accessibility requirements influence what evidence is necessary. A demonstration for one organiser at an empty workshop does not establish performance during a busy registration period.
Quality requirements should be measurable where measurement is appropriate, but not every important user need becomes one convenient number. Clear language and understandable recovery paths still deserve direct evaluation.
3. The smallest useful version still needs a complete boundary
A first release can omit optional features. It cannot omit a behaviour essential to making its central promise honest. Our booking service might begin without discount codes, but it still needs a defined answer when a workshop is full.
Scope reduction is therefore a design decision, not permission to abandon important invariants. A manually handled refund route might be acceptable for an early version if it is explicit and operationally supported. Pretending an unimplemented refund button works would not be.
Write down both inclusions and exclusions. The first version might support one organiser and fixed-capacity workshops, but not transfers between organisations. This limits what must be implemented while preserving clarity about what users can rely on.
A smaller complete promise is often more useful than a larger interface whose unsupported branches only appear after someone depends on them.
Part II: Architecture makes responsibility visible
4. Separate the interface from the authoritative decision
The browser presents information and collects a request. It should not be treated as the sole authority on whether a place still exists. Another request may have changed the shared state since the page loaded.
In our conceptual design, a server-side booking component evaluates the request against the authoritative record. A persistence component stores the result. A notification component communicates it. The interface then shows the observed outcome.
These are responsibilities, not a mandate for separate deployed services. One well-structured application may implement all of them. Splitting a small application into many networked services can add failure modes without adding useful independence.
The architectural question is where an important decision belongs and how its result crosses boundaries. The diagram should make it possible to identify who owns capacity, reservation identity, notifications and recovery.
5. An interface contract carries meaning, not just field names
Suppose one component sends a field named available. Does it mean the workshop exists, registration is open, a place was free at the time of a query or a place has already been held for this participant? Those meanings support different actions.
A useful contract defines inputs, outputs, preconditions, error meanings and timing. It says whether a returned identifier refers to a request or a completed reservation. It explains whether an operation can be retried safely and how an uncertain outcome is reconciled.
The contract also needs compatible units and representations. A timestamp without its time basis can be misinterpreted. A monetary amount without currency and rounding rules is incomplete. A missing field may mean unknown rather than zero.
Syntax validation catches malformed messages. Semantic agreement catches the deeper problem of well-formed messages that mean different things to the sender and receiver.
6. Dependencies belong in the failure model
Imagine that the application depends on a database and an email provider. The database becomes temporarily unavailable. That prevents new authoritative booking decisions. The email provider becomes unavailable. That might delay notifications without invalidating already stored reservations.
Those failures require different responses. Treating every dependency problem as “booking failed” could invite duplicate attempts after a reservation already exists. Treating every problem as success could create a promise with no supporting record.
For each dependency, ask which user-visible claim it supports and what remains possible when it is unavailable. A fallback should preserve the central rules, not merely keep the screen active.
This is architectural reasoning before implementation. The organisation can decide whether to queue notifications, provide a status lookup or temporarily stop taking requests without pretending that all interruptions are equivalent.
Part III: State is what the system must remember and protect
7. Model the reservation lifecycle explicitly
Our fictional reservation can be requested, held, confirmed, cancelled or expired. These labels are useful only if their effects are defined. Does a held place count against capacity? When may it expire? Can a confirmed booking return to held?
For this teaching model, a held or confirmed reservation occupies one place. Cancellation releases it once. An expired hold cannot later become confirmed without a new authoritative decision. A notification’s delivery state is tracked separately from the reservation state.
| Event | Required prior state | Intended result |
|---|---|---|
| Allocate an available place | Valid request and sufficient capacity | A recorded hold with a defined identity |
| Confirm a valid hold | Hold remains eligible | One confirmed reservation |
| Cancel | Active reservation under the cancellation rules | Cancelled state and capacity released once |
| Expire a hold | Hold has passed its defined validity condition | Expired state, not a hidden confirmation |
| Retry notification | Reservation outcome already recorded | Another delivery attempt, not another reservation |
This is a simplified state model, not a complete production design. Its value is that invalid transitions become discussable before they become scattered conditions throughout the code.
8. An invariant states what must remain true
An invariant is a condition the intended system preserves across permitted operations. For the booking example: occupied places never exceed capacity, each logical reservation has one identity, and a cancellation does not release the same place twice.
These statements should influence more than one test case. They guide the data representation, transaction design, recovery logic and monitoring. A design that can preserve an invariant only when requests arrive politely one at a time is not sufficient for a concurrent service.
Also distinguish invariants from targets. A response-time objective may tolerate a defined proportion of slow requests. Overbooking may be forbidden for this particular business rule. The acceptable treatment of exceptions depends on the requirement, not a universal software slogan.
A useful review asks which operation could violate each invariant and where that operation is prevented or detected. This turns a broad promise into a set of accountable design questions.
9. Data quality begins with definitions
A workshop identifier should not change merely because its display title changes. A participant’s contact information should not be confused with the identity of a reservation. A record of a payment attempt should not automatically imply a settled payment.
For our example, distinguish absent, unknown and not applicable where the task requires those meanings. A blank cancellation time could mean the reservation has not been cancelled, but a missing import value might mean its history is unknown. The application must not silently merge those situations.
Data also has provenance and time. A cached availability count is an observation from a moment, not an everlasting guarantee. The interface can use it for guidance while making the final decision against current authoritative state.
Good data modelling reduces the amount of interpretation every later component has to invent. It is an investment in shared meaning, not merely database tidiness.
Part IV: The last-place problem exposes the real mechanism
10. Reading a value and acting on it are not automatically one operation
In a conceptual failure sequence, request A observes one place remaining. Request B also observes one place before A has completed its update. Each then proceeds from an individually plausible observation, but the combined result exceeds capacity.
The lesson is about coordination, not the visual speed of the interface. The availability decision and allocation must be protected as a coherent operation under the chosen data system’s concurrency semantics.
Transactions group database work into a unit with all-or-nothing behaviour. PostgreSQL’s tutorial explains transaction blocks, commit and rollback. The appropriate isolation and constraints still need to be chosen for the actual invariant; merely wrapping arbitrary statements in a transaction does not prove that every concurrency problem is solved. Source: PostgreSQL, Transactions.
A production implementation requires database-specific design and testing. This guide does not prescribe a shortcut that should be copied into an unexamined booking or financial service.
11. A timeout means the observer lacks an answer
Suppose the server records the reservation, but the response is lost before reaching the browser. The browser times out. From the user’s perspective, the outcome is unknown; from the database’s perspective, the reservation may already exist.
Automatically treating the timeout as proof of failure creates a dangerous reasoning gap. A new attempt could duplicate an already completed effect. Automatically treating it as success is equally unjustified when the operation may not have reached the server.
The conceptual repair is reconciliation: retain a stable request identity and provide a way to determine its authoritative outcome. The interface can say that confirmation is being checked instead of inventing certainty.
This distinction generalises beyond bookings. Sending a request, receiving an acknowledgement, completing an action and observing the completed action are separate events. Dependable software keeps them separate until evidence connects them.
12. Retry safety belongs to the meaning of an operation
Repeating a read is different from repeating an action that allocates a place. An idempotent operation has the same intended effect when repeated with the same request as when performed once. HTTP defines idempotence in terms of intended server effects, not a guarantee that every repeated response is byte-for-byte identical. Source: RFC 9110, Idempotent Methods.
For our teaching model, retrying a logical booking should reconcile to the same operation identity rather than create another reservation. The design must define the scope and lifetime of that identity and what happens if a supposedly identical key is presented with different data.
There is no magic “exactly once” label that removes every boundary problem. Storage, messaging and external providers may each have their own semantics. The system must explain how duplicate requests, lost acknowledgements and delayed work are handled together.
The useful question is not simply “can it retry?” It is “which effect can repeat, which must not, and how does the system know the difference?”
13. A local transaction does not automatically include the outside world
Our database and email provider do not become one atomic system merely because the application calls them from the same function. A reservation can be committed while notification delivery fails. Conversely, a message could be sent before a later database operation fails.
A conceptual design can record the committed reservation and the need to notify, then process delivery with a retryable, observable workflow. The notification should refer to the recorded reservation rather than create a new one. Its delivery history remains separate.
Payment introduces additional responsibilities and provider-specific rules. This article does not design a production payment workflow. It makes the boundary visible: an external effect may require reconciliation or compensation rather than a simple reversal of a local record.
A dependable system knows which actions are reversible, which require a compensating action and which have already changed the world in a way that cannot be erased by deleting a row.
Part V: Evidence turns an implementation into a justified release candidate
14. Test cases are claims about behaviour
A useful test specifies a starting state, action and expected result. “Test booking” is too broad. “With one free place and no competing request, a valid booking produces one recorded reservation and reduces availability by one” is a checkable claim.
Now vary the conditions. The workshop is full. The request is repeated. A hold has expired. A participant cancels twice. A notification provider is unavailable. These cases are selected because they challenge the promised behaviour, not because a test-count target needs more entries.
Keep test data fictional or appropriately protected. A developer does not need a real child’s name and contact details to test a capacity rule. The representation required for the test should be no more sensitive than necessary.
The test suite becomes a living account of what the team believes the software should preserve. When the requirement changes, the relevant expectations must change deliberately rather than being patched merely to make the suite green.
15. Different test levels expose different failures
A unit-level test can examine a small calculation or decision in isolation. An integration test examines whether components agree at their boundary. An end-to-end test follows a user-relevant route through the assembled system.
For our booking service, a correct capacity calculation does not establish that the database update uses the same meaning. A successful database test does not establish that a screen-reader user can understand the outcome. An end-to-end happy-path demonstration does not establish every retry or concurrency condition.
The test strategy should therefore match the structure of the risk. Use smaller tests for precise, fast feedback and broader tests for the interactions that cannot be established locally. Do not force one level to pretend it proves everything.
SWEBOK treats testing as a distinct knowledge area within the complete engineering discipline. It is part of the evidence, not a substitute for requirements or architecture. Source: SWEBOK topic map.
16. Properties catch whole families of cases
Instead of checking only one cancellation example, state a property: cancelling an already cancelled reservation does not release additional capacity. Instead of checking one list order, state that every reported confirmed reservation refers to an existing workshop.
A generated set of test inputs can explore many cases against such properties. The value comes from the quality of the property and generation strategy, not simply the number of cases executed.
Boundary examples are especially useful: zero capacity, exactly full capacity, one place remaining, an expired hold, a missing identifier and unusually long but permitted text. The system should either handle a valid case or reject an invalid one clearly.
A property test still does not prove the entire deployed system. It is evidence within its model and execution conditions. The broader operating and integration claims require their own checks.
17. Passing tests does not eliminate the unknown
A test suite contains selected inputs and expectations. It can fail to represent an important environment, dependency behaviour or user need. The suite may also encode the same mistaken assumption as the implementation.
For our service, every automated test might assume messages arrive promptly. A delayed notification could then expose a user confusion that the tests never considered. The code can satisfy its test suite and still fail the intended service.
Review, exploratory evaluation and observation contribute different evidence. They should challenge assumptions rather than merely confirm that the current implementation behaves like itself.
The honest release question is not “have we proved the absence of every defect?” It is whether the evidence is appropriate to the requirements and consequences, which uncertainties remain, and how those uncertainties will be bounded and monitored.
Part VI: Security, privacy and accessibility are part of the product
18. Secure development begins before a final security check
NIST’s Secure Software Development Framework describes practices that can be integrated into a software development lifecycle to reduce vulnerabilities and address their causes. Security is therefore an engineering responsibility throughout development, not merely a final scan attached to an otherwise finished product. Source: NIST, SSDF.
For the fictional booking service, define who may view a reservation, change capacity, cancel another person’s place or export participant information. Authentication establishes an identity claim; authorisation determines which actions that identity is permitted to perform.
Use maintained components, protect secrets, review sensitive changes and plan an appropriate response to reported weaknesses. Testing should occur only within authorised environments and scope. No exploitation procedure is needed to understand these responsibilities.
A public-facing interface should not be credited with security merely because an unauthorised button is hidden. The authoritative action needs the appropriate permission check where the action is actually performed.
19. Privacy changes what the system should collect
Our organiser needs enough information to administer a workshop, not an unrestricted profile of the participant. Define the purpose of each data field, who can access it and how long it is needed.
Logs also deserve attention. A useful technical trace might need a request identifier and event time without including the participant’s full message or contact details. Debugging convenience is not a sufficient reason to copy sensitive data into every system.
This is a design principle, not jurisdiction-specific legal advice. Applicable privacy duties depend on the real service, data and location and should be reviewed by the responsible organisation.
The engineering question is concrete: can the intended function and investigation be supported with less sensitive information? A simpler data footprint can make access, retention and correction easier to manage without weakening the service.
20. Accessibility tests whether the interface serves its actual users
W3C describes web accessibility in terms of people with disabilities being able to perceive, understand, navigate, interact with and contribute to the web. It involves technologies and practices beyond visual styling. Source: W3C Web Accessibility Initiative.
For our booking service, consider keyboard operation, meaningful form labels, understandable errors and a status message that does not rely only on colour. A user should be able to discover which field needs correction and whether their booking has completed.
An automated check can identify some problems, but it is not a complete evaluation of the interaction. A perfectly labelled button can still lead into a confusing workflow. Real task-based review remains necessary.
Accessibility is not an optional decoration after the core product. If a person cannot complete the promised action through the available interface, the service has not fulfilled that promise for them.
Part VII: Release is a controlled change to a running system
21. Version control preserves what changed and why
A useful change history connects a modification to its purpose, review and evidence. It helps a later engineer distinguish an intentional rule from an accidental implementation detail.
For the booking service, a change to hold duration may affect the interface, expiration logic, notifications and tests. Recording only a changed number leaves the reasoning distributed across people’s memories.
Review should examine the requirement and consequences as well as code style. Does the change preserve capacity rules? Can older requests still be reconciled? Which operating assumption has changed?
A small change can have a large semantic effect. Conversely, a large internal refactoring can preserve public behaviour if that preservation is carefully designed and verified. The number of edited lines is not a reliable measure of user consequence.
22. A reproducible build connects source to the delivered artefact
The source repository is not identical to the running application. Dependencies, configuration, build tools and packaging help determine what is produced. A release record should identify the artefact actually deployed.
Imagine a test environment uses one dependency version while the production build resolves a newer one. The earlier test result may no longer describe the delivered artefact. The issue is evidence identity, not whether the dependency is popular.
A controlled process records enough information to reproduce or investigate the release, protects the build path and distinguishes test configuration from production secrets. This supports the secure-development practices described by NIST without treating the build system as inherently trustworthy. Further reading: NIST SSDF.
The claim should remain precise: this source and configuration produced this artefact, and these checks were performed on it. That is stronger than saying the project passed tests sometime before release.
23. Database changes need a compatibility plan
Suppose a new release expects an additional reservation field, but some running components still use the old record shape. Deploying the application and changing the database are distinct transitions.
A compatibility plan considers the order of those transitions, the period when old and new versions coexist, and the meaning of older records. A default value should not invent information the system never collected.
For our example, an additive field might be introduced before every reader depends on it. Data can then be checked and migrated under an explicit plan. The appropriate method depends on the actual system; no universal migration recipe fits every database and workload.
The important principle is that change has intermediate states. A final schema can be internally sensible while the route used to reach it breaks a running service.
24. Rollback is not time travel
Reverting an application version does not automatically undo messages sent, payments processed or data transformed by the newer version. Those effects may need separate reconciliation.
For the booking service, a rollback plan should explain whether the older application can read records created during the new release. If not, simply deploying the old binary may create another failure.
A bounded rollout can limit exposure and provide evidence before broader use. It still needs clear observation criteria and an authorised response when the result is unacceptable. Releasing to fewer users is not meaningful protection if nobody can detect the relevant problem.
The release decision should identify the expected change, the conditions that would trigger a stop and the state to which the service can responsibly return.
Part VIII: Operation measures the promise in the world
25. Service-level indicators need a denominator
A service-level indicator measures an aspect of service behaviour. A service-level objective sets a target for that measure over a defined period. Google SRE’s treatment distinguishes these from contractual agreements and stresses selecting indicators meaningful to users. Source: Google SRE, Service Level Objectives.
Original numerical example: suppose the booking service has an objective that 99.9 per cent of one million eligible requests succeed during a chosen period. The corresponding request-count allowance is 0.1 per cent, or 1,000 unsuccessful requests.
This does not mean the service is entitled to fail exactly 1,000 times, nor that any distribution of those failures is equally acceptable. Failures concentrated during registration may be far more consequential than the aggregate percentage suggests.
Define eligible requests, success, timing and exclusions in advance. Removing inconvenient failures from the denominator after the event turns the measure into a description of reporting choices rather than service quality.
26. A request-based percentage is not a downtime duration
A quiet service can have a long interruption while losing relatively few requests. A brief interruption during a demand peak can affect many. Request success and time availability therefore answer different questions.
For our invented service, report the measure that supports the actual promise and use complementary evidence where necessary. A workshop organiser may care about completing registration during a short opening period, not only a monthly average.
Likewise, an average response time can hide a slow tail. Two services with the same mean can give different experiences to the slowest users. Percentiles can help describe that variation, but their calculation needs enough relevant data and a clear definition.
Metrics should make experience more visible, not compress away the very group whose difficulty the system needs to address. A good operating report explains both the statistic and the boundary of its interpretation.
27. Worked latency model: parallelism helps only where dependencies permit it
Imagine a read-only summary page needing three independent internal results. Assign processing times of 40, 60 and 90 milliseconds, with another fixed 30 milliseconds of overhead. Ignore network variation, resource contention and scheduling costs.
Sequential execution takes 40 + 60 + 90 + 30 = 220 milliseconds. Under ideal parallel execution of the three independent tasks, the time becomes the maximum task duration plus overhead: 90 + 30 = 120 milliseconds.
The arithmetic does not justify parallelising dependent actions. A confirmation that requires an authoritative allocation cannot correctly be shown before that allocation is established merely to save time.
Parallel work can also increase resource contention and complicate failure handling. The useful engineering question is which tasks are genuinely independent, which result the user needs and whether the complete system improves under measured conditions.
28. Monitoring should reveal the service, not just the server
Google SRE describes latency, traffic, errors and saturation as useful signals for monitoring distributed systems. It also distinguishes symptom-oriented observation from the details needed to investigate causes. Source: Google SRE, Monitoring Distributed Systems.
For our booking service, a server can be running while reservations fail. An email queue can grow while the main interface still reports successful stored bookings. The monitor must observe the actual user-relevant states.
Useful logs, metrics and traces answer different questions. Counts reveal aggregate patterns. Event records reveal what happened to an operation. A trace can connect time across components. Their identifiers should make it possible to follow one request without unnecessarily exposing participant data.
An alert needs an actionable meaning and an owner. More alerts do not automatically create better awareness; an unmanageable stream can make the important exception harder to recognise.
Part IX: Maintenance preserves behaviour while conditions change
29. A defect repair needs a regression case
Suppose investigation shows that a repeated cancellation released capacity twice. Repairing the affected records addresses the immediate state. Changing the transition logic addresses the mechanism. Adding an appropriate regression test helps detect a recurrence.
The test should express the intended property, not merely reproduce one accidental arrangement of code. It should remain meaningful after the implementation is reorganised.
Then verify the deployed repair. A successful local test does not establish that the correct artefact reached the relevant environment or that historical records were reconciled.
A complete repair record connects the observed problem, affected scope, chosen change, evidence and remaining uncertainty. “Fixed” should mean that a defined claim has been restored, not simply that the ticket was closed.
30. Technical debt is a future constraint, not a moral label
An early design may deliberately accept a limitation to deliver a bounded useful service. The problem becomes more serious when the limitation is forgotten and later work assumes a capability that does not exist.
In our fictional service, a manual cancellation process might be manageable at low volume. Growth could make it a bottleneck or a source of inconsistent records. The right response is to compare the cost and risk of retaining it with the evidence for changing it.
Not every old component needs replacement, and not every new architecture improves the service. A rewrite can remove some constraints while introducing migration and operating risks.
Maintainability improves when boundaries, tests and documentation make changes understandable. The objective is a system that can continue serving its users, not a permanent race to adopt the newest tool.
31. AI-generated code is still code that needs engineering
A code generator can propose an implementation, explanation or test. The output does not independently establish that it satisfies the real requirement, handles concurrency or uses a supported dependency correctly.
For the booking example, fluent code can still encode the mistaken assumption that a timeout proves failure. A generated test may repeat that same assumption and appear to confirm the implementation.
The responsible process reviews the requirement, checks sources for changing interfaces, protects sensitive information and tests the actual artefact. Ownership of the release remains with the people and organisation making the promise.
This is a general evidence principle, not a comparison of particular models. Generating software faster can increase the amount awaiting verification. It does not reduce the importance of knowing what the software does.
Learning workshop: follow the promise through the system
Case A: the missing response. The browser times out after requesting a booking. What can it honestly conclude? Answer: it has not observed the outcome. The system should reconcile the stable operation identity rather than assume either success or failure.
Case B: the duplicate notification. A reservation exists, but its email failed. Should the retry create another reservation? Answer: no. Delivery is a separate workflow that should refer to the already recorded result.
Case C: the request budget. One million eligible requests have a 99.9 per cent success objective. How many unsuccessful requests correspond to the remaining fraction? Answer: 1,000. This request count is not automatically a duration of downtime.
Case D: the latency calculation. Three independent tasks take 40, 60 and 90 milliseconds with 30 milliseconds of fixed overhead. Answer: ideal sequential time is 220 milliseconds; ideal parallel time is 120. Real measurements must examine contention and other omitted costs.
Case E: the incomplete proof. Every unit test passes, but keyboard users cannot reach the confirmation action. Is the service ready for those users? Answer: the unit-test result did not establish accessible end-to-end use. That requirement needs its own evidence.
Case F: the unsafe rollback assumption. A newer version changed stored records, and the old version cannot read them. Is deploying the old version alone a valid rollback? Answer: not without a compatibility and reconciliation plan. Code reversal does not erase changed data.
Case G: the shared mistake. Implementation and tests both assume that a visible green tick means a stored booking. What should a reviewer ask? Answer: which authoritative evidence establishes the reservation and whether the interface is displaying that evidence rather than merely acknowledging a click.
How to teach software engineering without beginning with syntax
For younger learners, use cards representing a small number of workshop places. Let two pupils request the last place and ask the class to devise a clear allocation rule. Then add a repeated request and a lost acknowledgement. The problem becomes understandable before any programming language appears.
For Secondary learners, model states and transitions, define invariants and write plain-language test cases. Ask them to distinguish invalid input from unavailable service and unknown outcome. These are different states deserving different responses.
For advanced learners, introduce transactions, concurrency, distributed effects, compatibility and operational measures. Require a clear account of which guarantees belong to which component.
The final task should be to design a small complete service and explain its evidence. A sophisticated interface with unsupported promises should not receive more credit than a modest one whose behaviour and recovery are well understood.
Frequently asked questions
How is software engineering different from computer science?
The fields overlap. Computer science supplies theories and methods for computation. This guide focuses on constructing and maintaining a dependable software service under real requirements and operating constraints. The companion Computer Science guide follows the broader computational foundations.
Is a popular framework enough to make an application reliable?
No framework settles the application’s requirements, data meaning, external effects or operating procedures by itself. A tool can support an implementation while the complete service still contains an unresolved design error.
Does more testing always mean better evidence?
Only when the additional tests examine meaningful claims and conditions. Thousands of repetitive happy-path cases can miss one important boundary. Coverage measures and test counts need interpretation.
Why not make every service a separate microservice?
Separation can support independent responsibility and change, but it also creates network and coordination boundaries. The appropriate architecture depends on the actual job. A well-structured single application can be the better fit for a small service.
What is the strongest sign that software is finished?
There is no one permanent sign for a changing service. A release can have a defined acceptance decision supported by evidence, while maintenance, monitoring and future corrections remain ongoing responsibilities.
Working glossary
Requirement: a specified behaviour or constraint. Architecture: the arrangement of responsibilities and their relationships. State: the relevant recorded condition of the system. Invariant: a condition preserved by permitted operations.
Transaction: a coherent unit of database work with defined completion semantics. Idempotence: repeated execution with the same request having the same intended effect as one execution. Reconciliation: establishing authoritative state when observations are incomplete or disagree.
Regression test: a check intended to detect the return of an unwanted behaviour. Deployment: placing a software artefact into an operating environment. Service-level indicator: a defined measure of service behaviour. Service-level objective: a target for that measure.
Observability: the ability to infer relevant internal behaviour from available evidence. Compatibility: the ability of versions or components to interact under an agreed contract. Compensation: a new action that addresses the consequence of an earlier external effect without pretending the earlier event never occurred.
Evidence and scope
The booking service, state table, numerical examples and teaching activities are original. They establish reasoning within stated assumptions, not a validated production service. Real deployments need technology-specific engineering, appropriate security review and compliance with applicable duties.
Primary reference routes include the IEEE Computer Society’s SWEBOK overview and topic map; PostgreSQL’s transaction tutorial; IETF HTTP semantics; NIST secure-development guidance; W3C accessibility guidance; and Google’s first-hand SRE treatments of service objectives and monitoring. Product documentation and interfaces can change; implementation decisions should use the version relevant to the actual system.
The deeper answer: software engineering preserves meaning through change
The two green ticks at the beginning were not two successful bookings. They were two representations whose relationship to the authoritative state had broken.
Software engineering connects intention, representation, execution and evidence. It makes the normal path useful, the abnormal path understandable and the next change accountable. The finished product is not merely code that runs. It is a service whose important promises remain true as people, requests, dependencies and versions interact.
Continue: Mechanical Engineering connects software requests to physical action; Aerospace Engineering examines integrated flight systems; Environmental Engineering follows monitored outcomes in the environment. Return to the How X Works Hub for the complete subject library.