One of the goals of this course is to teach you some fundamental techniques for developing large-scale software. But it is not feasible to ask you to write large-scale software, so you will use large-scale techniques on small-scale software.
Even small-scale software can be formidible to write if not approached in a sensible way. Without discipline, you will be tempted to take what appear to be shortcuts, but that actually take you into a vast swamp where your feet get stuck in the mud. Instead of making progress on your project, you will spend all of your time trying to get out of the swamp.
The smart thing to do is to resist the temptation to go into the swamp, and instead to adhere to sensible software development principles.
|
A student 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. He said that he had started with his initial attempt, which he found did not work, and then had spent 8 hours making random changes to it. 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 for that! |
Here are some ideas that look like shortcuts but that actually take you into the swamp, and are anything but shortcuts.
Coding without planning. It is tempting to concentrate on the final product, a computer program, right from the beginning. That is, start coding right away, rather than starting with plans that are not part of the final product.
That is about as successful as building a skyscraper without bothering to draw up plans or to work out the construction phases in advance. Coding without planning takes you into the heart of the swamp.
This course will emphasize the importance of planning before coding. Methods of planning are part of the course.
Open guessing. Guesses have a place, but watch out for guessing when you are writing computer software. Open guessing is guessing without carefully checking whether the guess makes sense. It is a sure route into the swamp. Guessing is a software developers enemy.
Debugging by guessing. When your program does not work, you are tempted to think "I don't really need to know why it doesn't work. I just need it to work." So you try making a random change to see if that helps. No? Try another random change.
Would you go to a doctor who does not want to bother with diagnosis, and just tries random medications?
Random guessing is a sure time waster. The more you make random changes, the further your software gets from being correct.
Suppressing warnings. Compilers give warnings when you do things in suspicious ways that are likely mistakes. Some students have a way of dealing with that: they turn off warnings. The result is that mistakes that easily could have been found and fixed by reading a warning message instead require laborious debugging to fix.
Using a compiler or IDE as a crutch. When you get a compile error, the form of the error message typically seems to suggest a way to fix the error. But that suggestion is often not the right way to fix the error.
For example, if the compiler complains that there is no variable called s, the obvious thing is to create one. But maybe s is a typo, and should have been z.
A compiler is an excellent adviser but a terrible boss. You must be the boss. Look at what the compiler says and look carefully at your program. Then make an intelligent decision on what to do.
Integrated development environments (IDEs) such as Microsoft Visual Studio, XCODE, and Eclipse, offer a collection of useful tools. Sometimes, they present options or make suggestions. Do not expect that advice to be good. Remember, the IDE does not know what your program is supposed to do, so it cannot offer intelligent advice. If you use the tools that an IDE offers, be sure that you are using them as tools, not a crutches.
I do not recommend using an IDE at this point in your careers. There is too much temptation to use it as a crutch. Students who use IDEs often jump into coding without planning. They assume that the IDE will carry out the planning for them.
Those are some ways of getting into the swamp. What you want, of course, is to know how to stay out of the swamp. That is too large a topic to cover on this page, but it will be the subject of other pages in these notes.
In this course, we will discuss methods for developing software that have been proved useful. It is up to you do decide to use them.
Why is debugging by guessing not a good idea? Answer
Why shouldn't you suppress warnings? Answer
What is a danger in using an integrated development environment? Answer
The software that students write in this course is not large, Why should students use techniques that are suitable for large-scale software? Answer