Company Manual (View All)

Preface

Teaching software engineering in a classroom setting is an inherently tough challenge.

      Some of the most fun I ever had teaching software engineering was in the Oregon Master of Software Engineering program in the 1999-2000 academic year. It was fun because the program was for working professionals (kind of like a professional MBA program) which meant that for the most part they already understood why this stuff was important. One of my students in OMSE 500 was a section manager at Hewlett-Packard in Corvallis, Oregon. When you're teaching software engineering to someone actively managing 50+ software engineers in a world-class technology company, you'd dang well better know what you're talking about and how it applies in the real world. This guy's garbage meter would go off in 10 minutes if what I was teaching wasn't relevant. I loved the challenge and the environment.

      In the OMSE environment, we didn't do labs or form into teams, or build software. The reason is because everyone in the class was already doing that 50 hours a week. What they needed was some information to fill in the gaps, stuff they could read tonight and apply on the job tomorrow morning. So that was our approach, and it worked beautifully.

      Fast forward to BYU a few years later as I try to bring software engineering excitement to some of the brightest undergraduate Computer Science majors in the world (yeah, that's you).

      My first challenge is that as a group you possess only a fraction of the real experience that my OMSE students had. That means that you may struggle to grasp the relevance (or in some cases, the absolute criticality) of certain topics. You may not understand why I will assert with a straight face that you can solve P=NP and still lose your shirt (and your company) if you don't understand the stuff we're talking about in this class. That's not your fault. It's largely a function of time and experience — most people who have lived in the world of product development get this and most people who haven't, don't. Importantly, most of the people who have lived in the world of product development and who do get this, still have a great deal to learn in order to be successful at it.

      It sets up an inherently difficult pedagogical dilemma: In 16 weeks I can give you a throw-away toy project that will only remotely resemble the real world while risking the loss of focus in certain detailed areas, or I can give you a lab-based experience in which you learn deeply about certain topics while not even attempting to approximate a project experience. In either case, when the semester ends you toss whatever you did, which does not remotely resemble the real world. I've been tweaking my approach (sometimes radically) for more than 10 years, and what you see before you is the latest and greatest incarnation of my attempt to teach software engineering to bright but inexperienced undergrads in the most effective way possible. One significant aspect is the company that will quickly form for the semester.

      As you dive into this company manual, I want you to keep one thing in mind: Nothing that we are doing is fake or mocked-up for your educational edification. It may only last 16 weeks, but what we're doing is absolutely real. For the past seven years we have been involved in an on-going project called "The 20-Minute Genealogist." Our dilemma now is that the product actually shipped, leaving us at a point of project discontinuity. In other words, we're starting from scratch in Winter 2013. Given the large class size, that means we'll actually be launching a number of projects, more than one of which may become a persistent project pursued by future students in CS 428. Independent of the project you pursue this semester, you should consider the product to be real. You have a charter for 16 weeks to push your project down the path a bit and to leave it in a condition that the next generation of students can pick up where you left off.

      Most of the organization and process that will emerge this semester will be determined by you. The optimal organization in a given semester is a function of the people who show up as well as the particular phase of the project at that point in time. As a consequence, this company manual is intended to give you a leg up in your thinking, without solving the particular challenges and problems that are yours to solve.

      By having something real and meaningful to work on this semester, it's my hope that you pour yourself into the work with a bit more sincerity than you might if you knew it was all a throw-away skills acquisition exercise just to get a grade or graduate. In the midst of this live laboratory experience, it's my hope that you find fertile ground to apply the principles and precepts we're learning along the way.

      Prof. Charles Knutson