Taylor Venable committed 07ea25a

Add a very high level document about software engineering.

Comments (0)

Files changed (1)


+#+TITLE: Software Engineering
+#+AUTHOR: Taylor Chriſtopher Venable
+#+OPTIONS: H:6 toc:2
+* Introduction
+  This document is a very ambitious effort to document my thoughts and experiences in software
+  engineering, as experienced through the lenses of different jobs and positions. I'm still rather
+  young, so I fully expect this to evolve as my career (and the industry) does.
+* Overview
+  Software engineering entails many aspects of software development. I break it up into the
+  following broad categories, which will receive their own major sections below:
+  - discovering requirements
+  - planning / scheduling
+  - implementation
+  - testing / validation
+  - deployment
+* Methodologies
+  There are numerous established methodologies which standardize and formalize, to varying degrees,
+  aspects of the software development lifecycle. They can be broken down into two major groups:
+  linear and incremental. It's important to realize that despite popular (and vocal) opinion,
+  neither approach is universally better or worse than the other. Each has its own strengths and
+  weaknesses, and most importantly, situations where it is more likely to succeed or fail.
+** Linear
+   Often called after its most often-cited methodology, the so-called "waterfall" approach. The
+   defining characteristic of the linear method is its one-shot nature: the project gets underway,
+   is completed, and maintenance takes over essentially forever. This approach is traditionally
+   considered suitable for building large, complicated, expensive projects using many individuals of
+   varying skill level, who are organized into a hierarchical management structure. The focus is on
+   eliminating risk at each stage, so that the work products of that stage can safely be used to
+   start the next stage.
+   It's worth noting that this approach isn't just for software: in fact, this methodology is
+   descended from the nearly identical approach in classical engineering (from bridges to rockets).
+   This was back when computer programming was heavily involved in hardware development, a costly
+   and time-consuming process that made rapid iteration nearly impossible. These systems were also
+   very difficult to update after-the-fact, so it was acceptable to design a machine, program it,
+   and let it run for years. The process was successful in the projects for which it was well
+   suited; some of these ancient systems still perform key functions in large corporations,
+   industrial plants, and military and government facilities.
+   At the dawn of computing, the linear approach was perfectly suitable for most projects: they were
+   complex, multi-year projects involving hundreds of people and the delivery of both hardware and
+   software. However, as the industry matured, hardware became more multi-purpose, and software
+   crept into more and more areas. Projects got smaller, required less specialized hardware (and
+   then none at all), and had smaller budgets and shorter deadlines. The linear model was not
+   appropriate for these new kinds of projects, so a new family of incremental methods was
+   developed.
+** Incremental
+* Discovering Requirements
+* Planning / Scheduling
+* Implementation
+* Testing / Validation
+* Deployment