# Software Engineering — Stale course audit - URL: https://getstale.tech/run/web_20260428T073022Z - Target role: Backend Engineer Working On Real-Time Distributed Systems - Course focus: Software Engineering — Process, Lifecycle, And Project Management - Audit date: 2026-04-28T07:30:22Z - Verified findings: 4 - Structured data: https://getstale.tech/run/web_20260428T073022Z.json ## Findings ### 1. Outdated (medium severity) **Location:** L2-Ch2 SW Processes.pptx, Slide 15 **What the slide says:** > Collections of objects that are developed as a package to be integrated with a component framework such as .NET or J2EE. **Primary source:** https://jakarta.ee/about/faq/ (verified) > Java EE technologies contributed by Oracle are being used to create the new Jakarta EE platform... Initially Jakarta EE was the exact equivalent to the Java EE 8 platform. **What to learn instead:** Refer to Jakarta EE (the current standard maintained by the Eclipse Foundation since 2018) rather than 'J2EE'. The 'J2EE' brand was renamed to 'Java EE' with version 5 in 2006, and again to 'Jakarta EE' when stewardship was transferred from Oracle to the Eclipse Foundation. Modern equivalents include Jakarta EE and Spring. ### 2. Outdated (medium severity) **Location:** L2-Ch2 SW Processes.pptx, Slide 55 ('The SEI capability maturity model') **What the slide says:** > The SEI capability maturity model: Initial / Repeatable / Defined / Managed / Optimising **Primary source:** https://www.sei.cmu.edu/history-of-innovation/transforming-software-quality-assessment/ (verified) > Eventually, the Capability Maturity Model Integration (CMMI) framework, managed with software community guidance by the SEI for more than a decade, evolved from the Software CMM. **What to learn instead:** Teach the current CMMI maturity levels — Initial, Managed, Defined, Quantitatively Managed, Optimizing — rather than the retired Software CMM v1.1 levels (which used 'Repeatable' at level 2). The Software CMM was superseded by CMMI starting in 2002, and the CMMI product suite was transferred to the CMMI Institute (now part of ISACA) in 2013; CMMI V3.0 was released in 2023. ### 3. Outdated (low severity) **Location:** Ch1 Introduction.pptx, Slide 25 **What the slide says:** > Interface development technologies such as AJAX and HTML5 have emerged that support the creation of rich interfaces within a web browser. **Primary source:** https://www.w3.org/2019/04/WHATWG-W3C-MOU.html (verified) > HTML and DOM shall be developed principally in the WHATWG, following WHATWG Living Standard (LS) specification process... W3C agrees to discontinue its release plans for W3C versions of HTML 5.3 and DOM 4.1. **What to learn instead:** Refer to 'the HTML Living Standard' (maintained by WHATWG) rather than 'HTML5'. Since the May 2019 W3C/WHATWG MOU, the W3C stopped publishing versioned HTML 5.x recommendations and recognizes the WHATWG Living Standard as the single authoritative HTML/DOM specification. ### 4. Outdated (low severity) **Location:** L4-Ch23 Project planning-v2.pptx, Slide 67 ('The exponent term') **What the slide says:** > The company has a CMM level 2 rating. **Primary source:** https://www.sei.cmu.edu/history-of-innovation/transforming-software-quality-assessment/ (verified) > Eventually, the Capability Maturity Model Integration (CMMI) framework, managed with software community guidance by the SEI for more than a decade, evolved from the Software CMM. **What to learn instead:** Update worked examples to reference 'CMMI maturity level 2 (Managed)'. The standalone Software CMM was retired in favor of CMMI; certifications since 2002 have been issued against CMMI, not the original SW-CMM. ## Market fit Within its declared scope (software engineering process), the curriculum is a faithful 2014 Sommerville-style course — strong on UML, Scrum/XP, GoF patterns, COCOMO II, and CMM — but its three in-scope process artifacts that haven't kept pace with 2026 backend practice are tool-less version control (no Git), the absence of CI/CD pipelines (with the curriculum still asserting CI is 'practically impossible' at scale), and an architectural pattern catalog that stops at client-server and never reaches microservices. ### Git (modern distributed version control) (high) Version control is squarely in scope (configuration management is a core software-engineering-process topic and IS taught in Ch7). However, the curriculum teaches it only at the abstract 'version management system' level — Ch7 Slide 46 says 'Version management, where support is provided to keep track of the different versions of software components,' but never names Git, GitHub, branching strategies, pull requests, merge conflicts, or distributed version control. In 2026 this is the single most universal backend tool (9/12 postings demand it explicitly). The taught form is the 2014 Sommerville-era abstraction; the market form is hands-on Git fluency. For a real-time distributed systems specialization, Git is the substrate on which trunk-based development and continuous delivery sit. ### CI/CD pipelines (continuous integration and continuous delivery as a process practice) (high) Build/integrate/release automation is a software-engineering-PROCESS topic, not infrastructure — it belongs to this course's actual subject area. The curriculum touches automated test harnesses (JUnit) and 'frequent system builds' but never teaches CI/CD pipelines, build servers, or deployment automation. Worse, it teaches an outdated position: Ch3 Slide 53 explicitly states 'Continuous integration is practically impossible' (in the context of large-scale agile). That 2014-era assessment has been overturned in practice — 8/12 backend postings now require CI/CD as a baseline expectation. For real-time distributed systems, where multi-service deployment cadence and automated rollback are routine, the absence of CI/CD pipelines in the process curriculum is a substantive gap. ### Microservices architecture pattern (high) Architectural design is in scope (Ch6 is dedicated to architectural patterns). The curriculum teaches MVC, Layered, Repository, Client-Server, and Pipe-and-Filter (Ch6 Slides 23-38) — the canonical 2014 pattern catalog — but never introduces microservices, service decomposition, bounded contexts, inter-service communication patterns, or distributed-system trade-offs (CAP, eventual consistency, saga patterns). 8/12 postings list 'microservices' as a required or preferred skill. Given the user's specialization on real-time distributed systems, this is the single most directly relevant architectural gap: the student leaves the course able to draw a 4+1 view of a monolith but without vocabulary for the dominant 2026 distributed-backend architectural style. ## Recommended topics The three in-scope, market-validated process gaps are: (1) hands-on Git as the concrete instantiation of the course's 'version management' abstraction (75% of postings, 9/12), (2) microservices added to Ch6's architectural-pattern catalog (66.7%, 8/12) — the most directly relevant gap to the student's real-time distributed-systems specialization, and (3) CI/CD pipelines as a first-class process practice replacing the curriculum's outdated 'CI is practically impossible' position (66.7%, 8/12). Together these touch every one of the 12 backend postings analyzed. ### #1 Hands-on Git: distributed version control, branching strategies, pull requests, merge-conflict resolution, and trunk-based development (~14h to learn) Upgrade Ch7's tool-less 'version management' slide to a real Git workflow — the substrate every real-time distributed-systems team commits, reviews, and ships on. Keywords: git, branching, pull request, merge conflict, trunk-based development, distributed version control Where it fits: software_engineering · Configuration management / version management is already a declared topic in Ch7 Implementation (Slide 46). The natural fix is to replace the abstract 'version management system' treatment with a concrete Git module that still belongs to the process-and-lifecycle scope of the course — branching strategies, pull-request review workflow, and merge-conflict resolution are process practices, not infrastructure or framework knowledge. ### #2 Microservices architecture pattern: service decomposition, bounded contexts, inter-service communication, and distributed-system trade-offs (CAP, eventual consistency, saga patterns) (~18h to learn) Extend Ch6's pattern catalog past client-server into microservices — the architectural vocabulary 8 of 12 backend roles, and every real-time distributed-systems posting, expect graduates to already speak. Keywords: microservices, service decomposition, bounded contexts, cap theorem, eventual consistency, saga Where it fits: software_engineering · Architectural design is an explicit chapter (Ch6) and currently teaches MVC / Layered / Repository / Client-Server / Pipe-and-Filter. Microservices is the next architectural pattern in that same catalog — the addition stays inside the course's declared 'architectural patterns' subject area without bleeding into framework-specific implementation. It can be taught as a pattern with structure, when-to-use, and trade-offs, in the same shape as the existing GoF and architectural patterns. ### #3 CI/CD pipelines as a software-engineering process practice: automated build, integration, test, and release pipelines (~12h to learn) Replace Ch3's 'CI is practically impossible' slide with a real CI/CD pipeline module — the deploy-cadence backbone real-time distributed-systems teams rely on for safe multi-service rollout and rollback. Keywords: ci/cd, continuous integration, continuous delivery, build automation, release pipeline, automated rollback Where it fits: software_engineering · Build/integrate/release automation is squarely a software-engineering PROCESS topic — it is the modern realization of 'frequent system builds' and the test-harness culture the course already endorses (Ch3 TDD, Ch8 Testing). The fix also requires retiring Ch3 Slide 53's 2014-era claim that 'continuous integration is practically impossible' at scale, which is no longer the industry consensus. Treated as a process practice (pipelines, gates, automated rollback), it fits the course scope without crossing into infrastructure-tool teaching. --- Produced by Stale (https://getstale.tech). Request a course audit: https://getstale.tech/request-audit