updated lecture 2

24ss/slides/lecture_2/lecture_2.html

@@ -10,7 +10,6 @@
 <link href="lecture_2_files/libs/quarto-html/quarto-syntax-highlighting.css" rel="stylesheet" id="quarto-text-highlighting-styles"><meta charset="utf-8">
   <meta name="generator" content="quarto-1.3.450">
 
-  <meta name="author" content="Brian Loudin">
   <title>What is Software Engineering?</title>
   <meta name="apple-mobile-web-app-capable" content="yes">
   <meta name="apple-mobile-web-app-status-bar-style" content="black-translucent">
@@ -328,11 +327,6 @@
   <h1 class="title">What is Software Engineering?</h1>
 
 <div class="quarto-title-authors">
-<div class="quarto-title-author">
-<div class="quarto-title-author-name">
-Brian Loudin 
-</div>
-</div>
 </div>
 
 </section>
@@ -341,46 +335,46 @@ <h1 class="title">What is Software Engineering?</h1>
 <h1>Lecture 2: What is Software Engineering?</h1>
 
 </section>
-<section id="section" class="slide level2">
+<section id="section" class="slide level2 center">
 <h2></h2>
 <p><strong>Software engineering</strong> differs from <strong>programming</strong> in dimensionality: programming is about producing code. Software engineering extends that to include the maintenance of that code for its useful life span.</p>
 </section>
-<section id="section-1" class="slide level2">
+<section id="section-1" class="slide level2 center">
 <h2></h2>
 <p>There is a factor of at least <strong>100,000 times</strong> between the life spans of short-lived code and long-lived code. It is silly to assume that the same best practices apply universally on both ends of that spectrum.</p>
 </section>
-<section id="section-2" class="slide level2">
+<section id="section-2" class="slide level2 center">
 <h2></h2>
 <p>Software is sustainable when, for the expected life span of the code, we are <strong>capable of responding to changes</strong> in dependencies, technology, or product requirements. We may choose to not change things, but we need to be capable.</p>
 </section>
-<section id="hyrums-law" class="slide level2">
+<section id="hyrums-law" class="slide level2 center">
 <h2>Hyrum’s Law</h2>
 <p><br> <br></p>
 <blockquote>
 <p><em>“With a sufficient number of users of an API,</em> <em>it does not matter what you promise in the contract:</em> <em>all observable behaviors of your system</em> <em>will be depended on by somebody.”</em></p>
 </blockquote>
 </section>
-<section id="section-3" class="slide level2">
+<section id="section-3" class="slide level2 center">
 <h2></h2>
 <p>Every task your organization has to do repeatedly should be scalable (linear or better) in terms of human input. Policies are a wonderful tool for making process scalable.</p>
 </section>
-<section id="section-4" class="slide level2">
+<section id="section-4" class="slide level2 center">
 <h2></h2>
 <p>Process inefficiencies and other software-development tasks tend to scale up slowly. Be careful about boiled-frog problems.</p>
 </section>
-<section id="section-5" class="slide level2">
+<section id="section-5" class="slide level2 center">
 <h2></h2>
 <p>Expertise pays off particularly well when combined with economies of scale.</p>
 </section>
-<section id="section-6" class="slide level2">
+<section id="section-6" class="slide level2 center">
 <h2></h2>
 <p><strong>Because I said so</strong> is a terrible reason to do things.</p>
 </section>
-<section id="section-7" class="slide level2">
+<section id="section-7" class="slide level2 center">
 <h2></h2>
 <p>Being data driven is a good start, but in reality, most decisions are based on a mix of data, assumption, precedent, and argument. It’s best when objective data makes up the majority of those inputs, but it can rarely be all of them.</p>
 </section>
-<section id="section-8" class="slide level2">
+<section id="section-8" class="slide level2 center">
 <h2></h2>
 <p>Being data driven over time implies the need to change directions when the data changes (or when assumptions are dispelled). Mistakes or revised plans are inevitable.</p>
 </section>