<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Software Engineering on Antoine Boucher</title><link>https://antoineboucher.info/CV/blog/tags/software-engineering/</link><description>Recent content in Software Engineering on Antoine Boucher</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Mon, 13 Apr 2026 08:00:00 -0400</lastBuildDate><atom:link href="https://antoineboucher.info/CV/blog/tags/software-engineering/index.xml" rel="self" type="application/rss+xml"/><item><title>Software lifecycle notes — GOALS, waterfall, and verification vs validation</title><link>https://antoineboucher.info/CV/blog/posts/software-engineering-textbook-figures/</link><pubDate>Mon, 13 Apr 2026 08:00:00 -0400</pubDate><guid>https://antoineboucher.info/CV/blog/posts/software-engineering-textbook-figures/</guid><description>&lt;p&gt;These pages are from a &lt;strong&gt;software engineering&lt;/strong&gt; textbook I used in coursework. I grouped the figures here as a single reference: &lt;strong&gt;goal-oriented planning&lt;/strong&gt;, how the &lt;strong&gt;waterfall&lt;/strong&gt; model sequences activities (with &lt;strong&gt;verification and validation&lt;/strong&gt; paired to each phase), an &lt;strong&gt;incremental&lt;/strong&gt; variant, the textbook’s list of &lt;strong&gt;life-cycle subgoals&lt;/strong&gt;, a reminder that &lt;strong&gt;method advice depends on context&lt;/strong&gt;, and a short &lt;strong&gt;ethics&lt;/strong&gt; passage about impact on people.&lt;/p&gt;
&lt;h2 id="goals-approach-figure-3-1"&gt;GOALS approach (Figure 3-1)&lt;/h2&gt;
&lt;p&gt;The &lt;strong&gt;GOALS&lt;/strong&gt; flowchart is a top-down pattern: set &lt;strong&gt;overall life-cycle goals&lt;/strong&gt; (functions, constraints, schedule, usability, maintainability), &lt;strong&gt;analyze&lt;/strong&gt; the problem and sketch solution structure, &lt;strong&gt;separate concerns&lt;/strong&gt; into subgoals, &lt;strong&gt;develop&lt;/strong&gt; solutions for each subgoal in parallel where possible, then &lt;strong&gt;validate&lt;/strong&gt; those solutions against the other goals and &lt;strong&gt;iterate&lt;/strong&gt; until the decision “all goals satisfied?” is yes.&lt;/p&gt;</description></item><item><title>My journey in software engineering</title><link>https://antoineboucher.info/CV/blog/posts/software-engineering-journey/</link><pubDate>Sat, 30 Dec 2023 10:00:00 -0400</pubDate><guid>https://antoineboucher.info/CV/blog/posts/software-engineering-journey/</guid><description>&lt;p&gt;This site’s bio sums up the slice of the field I care about most: &lt;strong&gt;backend&lt;/strong&gt;, &lt;strong&gt;platform&lt;/strong&gt;, and &lt;strong&gt;DevSecOps&lt;/strong&gt;. This post is a longer look at how I think about that journey — not a timeline of jobs, but the ideas that kept showing up once I stopped treating “shipping features” as the only scoreboard.&lt;/p&gt;
&lt;h2 id="from-features-to-systems"&gt;From features to systems&lt;/h2&gt;
&lt;p&gt;Early on, progress often feels linear: tickets closed, endpoints added, screens shipped. That work matters. Over time, though, the interesting problems sit one level up: how services talk to each other, how failures propagate, how a change in one team’s repo affects everyone else on Monday morning. Backend engineering stops being “write the handler” and becomes “design something that stays understandable when you’re not in the room.”&lt;/p&gt;</description></item></channel></rss>