|
Production software (software that is intended for sale or for general use) tends to be large. A small piece of production software might be 1,000 to 10,000 lines long. Larger pieces of software can be 100,000 or 1,000,000 lines long. They are written by teams, not by one person.
Large changes of scale in almost anything usually make qualitative differences. Putting a log across a small creek might make an adequate bridge. Spanning a larger creek requires a different approach. Building a bridge across the Golden Gate can only be done with sound civil engineering practices.
Changes of scale in software similarly make qualitative differences. In a first programming course, most students learn an approach to software development that fails for software that is more than about 200 lines long. Really. That is the critical size where most people cannot keep every detail of the whole program in their heads at once. The critical size is a bit smaller for some, a bit larger for others, but there is a surprisingly small critical size for everyone.
Software requires details to be correct throughout. A single incorrect line can ruin it. Humans are not good at keeping track of so much detail.
That does not mean that writing software is hopeless! It means that you need to adopt methods that will scale up with the size of the software that you create, methods that do not require you to remember a lot of detail at once. We will see some of those methods in this course.
It is clearly not reasonable to ask you to write a 10,000 line piece of software for this course. You learn development methods suitable for large software by practicing them on small software.
Imagine that you are standing at the starting line, ready to get going on a programming assignment. You can visualize the final product; metaphorically, you see it, and you want to head directly toward it. Since the final product is code, you begin writing code. What could be more sensible than that, right?
Unfortunately, directly between you and the final product lies a swamp. If you walk into the swamp, your feet will get stuck in the mud. You cannot overcome that. The swamp represents the inherent difficulties in writing software that is larger than the critical size mentioned above.
But all is not lost. There is a road around the swamp that takes you to your goal. It is a little more indirect, but taking the road will take much less time than trying to slog through the swamp.
In spite of what you have been taught up to now, software is not written by sitting at a computer and typing. Software development requires planning using pencil and paper. Because you cannot remember everything that you have done, you need to document your work. Think of the swamp metaphor when you are considering skipping those steps.
|
A student once came to my office for help in writing a
function definition of about 10 noncomment lines.
He showed me his attempt, which made no sense at all.
We carefully planned it out, then wrote the code, in 20 minutes. Afterwards, the student remarked how similar our result was to the code that he had started with. But there were some small differences. Software is very sensitive to small mistakes, and his first try did not work. He said that, starting with his initial attempt, he began making random changes, hoping to hit upon the error that he had made. After 8 hours of that, by his estimate, he decided to ask for help. When I asked him why he had worked that way rather than planning first and debugging in a sensible way, he said that he did not think he had time to do that! |
|