Software Development Challenges

• You can already write a C++ program that works on your laptop. This course is about building software that other people depend on, with a team, over months and years.
• Each chapter adds one engineering practice; each lab applies it to one team project: ITC Club Hub, an application for student clubs at the institute.
• Teams of 4 to 5 analyse and model the full web and mobile system and implement its core in C++20: domain model, business rules, a command-line front end, CSV or JSON storage.
• This chapter asks the first question: why is building software hard, and what goes wrong when we ignore that?

• Software engineering: the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software (IEEE definition, used by SWEBOK Guide v4.0).
• A program is written by its author for its author. A software product is used by people who did not write it, on machines the author never saw, for years.
• Brooks (The Mythical Man-Month, 1975): making a program general, tested and documented triples the effort; making it fit into a larger system triples it again, so about 9 times in total.
• Engineering mindset: understand the problem before coding, make trade-offs explicit (time, cost, quality), measure instead of guessing, design for change, and take responsibility for the result.

• Brooks, No Silver Bullet (1986): the hard part of software is the essence, the concepts and their relations, not the accidents of writing them down in a language on a machine.
• High-level languages, time-sharing and IDEs removed large accidental difficulties. No single new tool can make the essence ten times easier: hence "no silver bullet".
• Each essential difficulty has practices that manage it; they are the chapters of this course (UML for invisibility, requirements for conformity, tests and version control for changeability).

xychart-beta
  title "Communication paths = n(n-1)/2"
  x-axis "Team size n" [2, 3, 4, 5, 6, 7, 8, 9, 10, 12, 15]
  y-axis "Paths" 0 --> 110
  bar [1, 3, 6, 10, 15, 21, 28, 36, 45, 66, 105]

Every pair of people who may need to agree on something is one path. With n people there are n(n-1)/2 pairs.

n =  5 :  5 × 4 / 2  =    10 paths
n = 10 : 10 × 9 / 2  =    45 paths   (×4.5)
n = 50 : 50 × 49 / 2 = 1 225 paths   (×122)

Club Hub team of 5 + the client (TA) = 6
       6 × 5 / 2 = 15 paths

• People grow linearly, paths grow quadratically: doubling the team from 5 to 10 multiplies the paths by 4.5.
• Brooks's law (The Mythical Man-Month, 1975): adding people to a late project makes it later, because newcomers need training and add paths.

Why the curve rises: everything built on a wrong decision (design, code, tests, data, user habits) must be found and redone.

Club Hub, rule misunderstood:
  client means "cancel up to 24 h before"
  team writes "cancel up to 2 h before"

Found in a requirements review:
  fix one sentence                   0.5 h
Found after release:
  fix code + tests                   3.0 h
  rebuild, re-release                1.0 h
  find and undo late cancellations   3.0 h
  apologise to 4 clubs               1.0 h
                                     -----
                                     8.0 h
Cost-of-change ratio: 8.0 / 0.5 = 16×

1 year = 365 × 24 = 8 760 h
99.9 %  ->  0.001 × 8 760 h = 8.76 h down

• Each extra nine costs far more than the last: redundancy, monitoring, people on call.
• Club Hub does not need five nines; it needs its rules to be right and its personal data to stay private. Choosing the right targets is Chapter 02.

#include <charconv>
#include <optional>
#include <string_view>

// The capacity column comes from events.csv, which people edit by hand.
// Reliability: never crash on bad data.
// Security: never trust input; reject anything unexpected.
std::optional<int> parseCapacity(std::string_view text) {
    int value = 0;
    const char* first = text.data();
    const char* last = text.data() + text.size();
    auto [ptr, ec] = std::from_chars(first, last, value);
    if (ec != std::errc{} || ptr != last) return std::nullopt;
    if (value < 1 || value > 500) return std::nullopt;
    return value;
}

// caller decides what "no value" means: skip the row and log it
if (auto cap = parseCapacity(fields[4])) {
    events.push_back(Event{/* ... */ *cap});
} else {
    log.warn("events.csv line {}: bad capacity", lineNo);
}

• A legacy system is one that still does valuable work but is hard to change: old technology, missing documentation, original authors gone. It cannot simply be switched off.
• Integration is where conformity bites: the other system decides the format of a student ID, the date format in a CSV export or the number of emails per hour.
• Typical integration failures: a field changes type, a date arrives as 03/11/2026 (3 November or 11 March?), an export silently drops rows, the other side is down.
• Defence: an adapter per external system, validated input (previous slide), and a written interface agreement with an owner and a version.

• Technical debt: the future cost of a quick-and-dirty solution chosen today. The principal is the work needed to clean it up; the interest is the extra effort every later change pays while it stays.
• Debt can be a good decision (ship the demo on Friday) if it is deliberate, recorded and repaid. Unnoticed debt is the dangerous kind.
• Forms: duplicated code, missing tests, hard-coded values, outdated dependencies, no documentation, "temporary" workarounds.
• Legacy systems are often systems whose debt was never repaid.

flowchart TD
  A["Ariane 4 alignment code reused<br/>still running after lift-off"] --> B["Ariane 5 flies faster:<br/>horizontal values much larger"]
  B --> C["64-bit float to 16-bit<br/>signed integer overflows"]
  C --> D["Unhandled Operand Error:<br/>backup and main unit shut down"]
  D --> E["Diagnostic data read<br/>as flight data"]
  E --> F["Full nozzle deflection at about 37 s:<br/>break-up and self-destruct"]

#include <cstdint>
#include <limits>
#include <optional>

// Ariane 4 assumption: the horizontal bias always fits in 16 bits
std::int16_t toBias(double horizontalBias) {
    // unchecked narrowing: undefined behaviour when out of range
    return static_cast<std::int16_t>(horizontalBias);
}
// toBias(40000.0): 40000 is outside [-32768, 32767].
// One MSVC x64 build printed -25536; another compiler may do anything.

// Checked version: the caller must decide what to do
std::optional<std::int16_t> toBiasChecked(double v) {
    using L = std::numeric_limits<std::int16_t>;
    if (!(v >= L::min() && v <= L::max())) {
        return std::nullopt;   // also rejects NaN
    }
    return static_cast<std::int16_t>(v);
}

mindmap
  root((SWEBOK Guide v4.0))
    Build the product
      Requirements · Ch 05
      Architecture · Ch 02
      Design · Ch 06
      Models and methods · Ch 06
      Construction · C++ labs
      Testing · Ch 09
    Run and evolve it
      Operations · Ch 08
      Maintenance · Ch 10
      Configuration management · Ch 08
    Organise the work
      Process · Ch 04
      Management · Ch 07
      Quality · Ch 09
      Economics · Ch 01
    Act responsibly
      Security · Ch 02, 03
      Professional practice · Ch 03
    Foundations
      Computing, mathematical and engineering · prerequisites

• The Software Engineering Body of Knowledge (IEEE Computer Society) describes what a software engineer with a few years of experience is expected to know.
• Version 4.0 (2024) has 18 knowledge areas: 15 engineering areas plus 3 foundations. New since v3: Software Architecture, Software Engineering Operations and Software Security.
• This course touches every engineering area once, at survey level. The Software Engineering and IT Project Management courses go deeper into construction, design, management and economics.
• Use the map when a topic feels isolated: it tells you where it belongs and which chapter treats it.