diff --git a/Lectures/L02_GettingStarted/GettingStarted.pdf b/Lectures/L02_GettingStarted/GettingStarted.pdf
index 89a956d99c55df10afdb814f79dc3ea8844ec7d4..0c141008b4f5b9d2aeeed217193da9fca5afa180 100644
Binary files a/Lectures/L02_GettingStarted/GettingStarted.pdf and b/Lectures/L02_GettingStarted/GettingStarted.pdf differ
diff --git a/Lectures/L02_GettingStarted/GettingStarted.tex b/Lectures/L02_GettingStarted/GettingStarted.tex
index 23199804861b568f3700b1446b51a1b637117abf..f04b2afae32613a162150b6e89d27f70a9ba8caa 100755
--- a/Lectures/L02_GettingStarted/GettingStarted.tex
+++ b/Lectures/L02_GettingStarted/GettingStarted.tex
@@ -358,65 +358,6 @@ First either init repo or clone (git init, git clone), then typical workflow is
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
-\begin{frame}
-\frametitle{SE For SC Literature}
-
-\begin {itemize}
-
-\item CAS 741 process is document driven, adapted
-from the waterfall model~\cite{GhezziEtAl2003, VanVliet2000}
-\item Many say a document driven process is not used by, nor suitable for,
-scientific software.
-\bi
-\item Scientific developers naturally use an agile
-  philosophy~\cite{AckroydEtAl2008, CarverEtAl2007, EasterbrookAndJohns2009, Segal2005}, 
-\item or an amethododical process~\cite{Kelly2013}
-\item or a knowledge acquisition driven process~\cite{Kelly2015}.
-\ei
-\item Scientists do not view rigid, process-heavy approaches,
-  favorably~\cite{CarverEtAl2007}
-\item Reports for each stage of development are counterproductive~\cite[p.~373]{Roache1998}
-\item Up-front requirements are
-impossible~\cite{CarverEtAl2007, SegalAndMorris2008}
-\item \structure{What are some arguments in favour of a rational document driven
-    process?}
-\end{itemize}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
-\begin{frame}
-\frametitle{Counter Arguments}
-
-\begin {itemize}
-
-\item Just because document driven is not used, does not mean it will not work
-\item Documentation provides many
-benefits~\cite{Parnas2010}: 
-\bi
-\item easier reuse of old designs
-\item better communication about requirements
-\item more useful design reviews
-\item easier integration of separately
-written modules
-\item more effective code inspection
-\item more effective testing
-\item more efficient corrections and improvements.
-\ei
-\item Actually faking a rational design process
-\item Too complex for up-front requirements sounds like an excuse
-\bi
-\item Laws of physics/science slow to change
-\item Often simple design patterns
-\item Think program family, not individual member
-\ei
-\end{itemize}
-
-\end{frame}
-
-%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
-
 \begin{frame}[allowframebreaks]
 \frametitle{References}