Lecture 1: Software Development
What is the purpose of this course? What are the goals?
Everyone can write a program that eventually does something useful for the programmer and his friends. A program becomes truly useful, however, when your grandmother can use it. Put differently, it has evolved into an application that you can sell or at least give away to uninitiated people. Or, your program has become a part of a large system of interacting pieces; in this case people tend to call it or a component.
Above and beyond addition to applications and components, companies often produce entire programming systems. Examples are operating systems, productivity suites, etc. These systems combine the qualities of applications with those of components.
In summar, there are four classes of programs:
The differences between the first and the remaining three are huge. While you, the super-duper hacker, can create a program after a couple of years of programming in your parents' garage while you're supposed to attend boring high school courses, you can't get away with that kind of activity if you want to create an application, a component, or a system. These things require documentation for external users (people other than yourself and your close friends who can read your programs to run them), continuous maintenance, port to new operating systems, adjustment to new user interaction modes, and so on. You can only achieve this goal if you construct this kind of software with a systematic process and leave behind code that truly, honestly works.
So, the real problem is this:
This someone could be a person that takes over the code from you. Or this someone could be a person who picks up your code long after you have left the project. Or this someone could be you, because your boss asked you to fix a bug or add a piece of functionality or whatever long after you had initially worked on it. You are a different person now; you have forgotten what you thought about and you can't possibly remember everything.
Corollary: Develop the program so that you can read and modify it a day later, a month later, or a year later.
See my Web page.
Brooks, The Tar Pit
How does the course help you develop these skills?
I use the idea of a studio course, which I have imported from the fine arts. You will
You will learn from your following our advice, your own activities, your presentations, and from watching others present.
When do you get the advice?
Some meetings will be plain lectures. Initially I will present some basic ideas and principles of software design and development. This will be followed with a discussion of some so-called software patterns in a specific context.
Later on, I will also present specific programming knowledge for specific tasks. For example, one of the projects will involve wiring together two components of a project via tcp sockets.
Some projects may require domain knowledge. I may present this as needed in lectures.
NOTE: In this course, I will attempt to keep the domain knowledge to a minimum so that we can focus on the development of software. Still, we cannot possibly write interesting software in a vacuum, and we cannot learn to develop software well with completely boring domains. So, you must be prepared to know something about the domain of application. In the real world, you will probably find out far more about domains than you ever wanted to know.
What kind of advice will I present?
Why all this partner stuff?
Designing code means thinking. By its very nature, thinking is a private activity. It is nearly impossible to debug thinking while it is private. Translating thoughts into code is one way to make them public, and the compiler and the test cases do expose some problems with your thinking. But they don't check whether you have truly understood the requirements, the interface or whether your thinking is completely off-base. If, however, you need to continuously discuss your thoughts with your partner, chances are high that mistaken assumptions are exposed quickly. The benefits are reductions in errors, debugging time, mistaken assumptions, mismatched interfaces and many more.
Why all this code review stuff?
Make no mistake, even two people can go wrong for a long time. And they hardly ever act as more than a single programmer with two brains and two mouths. A review panel on the other hand ensures that the two think of their audience: the customer, the current team members, and their future replacements (including older versions of themselves).
Overview of course pages; basic policies
|last updated on Tue Jun 9 22:03:19 EDT 2009||generated with PLT Scheme|