Alright, everyone, welcome back to Database Notes, the only podcast where we pride ourselves on not reading the notes—at least, not until moments like this. I'm Sophie Clarke, joined as ever by Emily Carter and Alistair Fraser. Today, we're untangling why software engineering is even a thing—because honestly, sometimes it feels like just an excuse for extra paperwork, doesn't it?Och, but there's a reason we ended up with all these formalities. I mean, there's this proper history, right? Go back to the late ’60s—1968, specifically. That NATO conference where folk started flinging around the term "software crisis". They weren't being dramatic for the sake of it; they were staring down massive failures. Monstrous projects spiraling out of control, over budget, delayed—some of them crumbling to bits at launch.Yeah, like, people sometimes think that's just old news, but listen, that stuff still happens. Ariane 5 is a classic. Ten years of work, something like seven billion bucks, and it explodes in less than a minute because of one—one!—software bug. Traced back to a specification error in the guidance software. All it took was mismanaging an assumption about what kind of data would be processed. Outdated approach, no systematic thinking.Exactly! It proves just how much was riding on these decisions. And let's not forget the Y2K bug—hard to overstate how panicked everyone was near the millennium. Developers saving a few bytes by writing 1975 as '75' instead of '1975'. Seemed clever at first, saving storage, right? But then you realize, come the year 2000, computers would think it’s 1900. That could—well, did—mess up bank calculations, negative loan interest, safety routines, even put lives at risk in critical systems.Funny now but terrifying then, aye. Not every country took it seriously either. Russia didn't, and suffered for it. The lesson? If you don’t engineer software properly, you risk system failure at a scale you really don’t want to reckon with.And you know, that's not just ancient history or big-budget horror stories. Startups blow up all the time because they skip the fundamentals. I think that's why, even now, this “crisis” idea repeats itself. Oh, Sophie—you said you had a story from early in your career, right? Something about banking systems?Ha, yes! My first real tech writing job, on a banking platform. I nearly botched a whole requirement spec because—get this—no one agreed if the bit in question was actually "software," or just a "script." Seems petty, but legal was involved, so it mattered. Arguments for days. I listed it as both in the docs just to cover myself. But it's exactly that ambiguity—and nobody owning the process—that leads to chaos, big or small.So, speaking of process, what actually *is* software engineering? Because a lot of folks just see programming—all code is the same, right? But there's, like, definitions! IEEE says it’s systematic, disciplined, and quantifiable approaches to developing, operating, and maintaining software. Much fancier than telling your cousin you “just make apps.”Aye, and if you go by the Canadian Standards Association, it’s all about systematic activities—design, implementation, testing—to optimize how we make and support software. Core thing is, it’s engineered—so you're not just programming. You're managing resources, people, constraints, the lot. It’s not like computer science, which is all about theory and computational concepts. And it's not quite systems engineering either, which is broader: policy, physical systems, hardware, deploying the whole shebang, sometimes with software along for the ride.And the unique nature of software throws everything off. Think about it: It's intangible, unlike, say, a bridge. Software doesn't 'wear out' in the same way—no rust, no crumbling under its own weight. But it's so ridiculously easy to modify on the fly, and just as easy to copy. That can be a blessing or a curse: changes everywhere, bugs multiplying, the original plan eroding one patch at a time.Totally. And because you can't *see* the effort—that dev behind the scenes slaving away? Management sometimes thinks, hey, why can’t you just whip up another feature overnight? “Isn’t it all copy and paste?” But, like, that attitude is what tanks projects, right? When there’s no systematic approach—everyone does whatever—they're late, buggy, impossible to maintain. And let’s not forget ethics. There’s actually a framework: act with public interest, maintain integrity, support your team, lifelong learning—all that. If nobody cares, you get, well, chaos.And when you set those standards aside, disaster follows. I’ve seen startups who thought skipping process would save time. Instead, projects dragged out, quality slipped, folk burned out—and they threw out what they’d built, started over. No exaggeration, IBM said 94 out of 100 software projects have to restart. That's not just bad luck, that's bad software engineering—no discipline, no ethics, no method.It’s true. The profession matters now more than ever, with demand for software engineers at an all-time high. CareerCast ranked it as the "all-around best job" back in 2012—still going strong today, with huge demand and rising salaries. But you don’t get there by winging it; it’s the process, the principles, that make the job—and the software—high quality and sustainable.Speaking of process, let’s jump into the fun bit: process models. Not the stuff of thrilling novels, but oh so necessary! There’s Waterfall, Incremental, Iterative, Prototyping, Spiral, Agile—each supposedly fits a different scenario, but how do you even choose?I always say, picking the wrong model can sink you before you’re afloat. Waterfall’s dead simple—everything in neat, sequential phases. But if you don’t know every requirement at the start, good luck making changes later. Incremental and Iterative—those are handy when things are expected to evolve. You keep adding bits, refining as you go. Prototyping’s for when nobody even knows what they want yet—build a fake version, get feedback, build again. Spiral? That’s all about constant risk analysis—smart if you’re working with huge, risky systems, but no good for wee projects. And Agile—well, folk love Agile because it’s about people, feedback, adaptability, not rigid planning. Great unless your team’s not ready for the discipline it demands.Yeah, let me tell you, “just do it all at once” does not work. My team, at a previous gig, tried this Big Bang thing—didn’t really have a plan, just sprinted straight toward a release. Multiple delays, stuff breaking everywhere. Eventually, after too many late nights, we gave in and started using Agile properly. Not just calling meetings “standups”—I mean, really doing iterations, reviews, short sprints, and—this is key—letting the team own the process. Things sped up. Bugs actually went down. It was…not magical, but real progress.And I wonder: if the Ariane 5 or even those Y2K systems had used something more adaptive or risk-aware—maybe Spiral or proper Incremental—would things have turned out differently? It makes you think. But, of course, choosing models depends on your team. The group's dynamics, level of experience, even how closely you can work with your users—all play a role, right?Aye, absolutely. One model won’t fit every team or project. Waterfall's fine for small, fixed projects; Spiral or Agile for large or risky undertakings. But if the team can't communicate, or the management demands impossible speed—well, it doesn't matter what model you picked, you're still likely to take a nosedive.So maybe that’s why we keep arguing over process models in every software engineering lecture and company kickoff. The best one is the one your people can actually use well—together. Otherwise, you’re just picking a new way to fail.Brilliantly put, Emily. And with that, we’ll wrap for today. We hope you enjoyed this breakdown of why software engineering isn’t just academic fuss, why systematic approaches matter, and how real-world failures keep shaping our field. We’ll be digging into more of these principles—and maybe even some more weird anecdotes—next episode. Thanks Alistair, thanks Emily!Cheers, Sophie, cheers Emily. Talk to you both next time. And listeners—mind your process models!Thanks, guys! And thanks, everyone, for tuning in. See you next episode!

Episodes

Why We Study Software Engineering