No matter what kind of software you're writing, your first version's likely to have bugs, lack necessary features, run too slowly, require too much space, or have a terrible user interface.

You can fix these problems by rewriting the software piece by piece, or you can throw it away and start over, or you can rewrite parts of it while discarding other parts entirely.

You're going to throw out that first system, anyway. Your plan and schedule should acknowledge that fact.

Fred Brooks's advice, that we should plan to throw one away, contributed to the popularity of rapid prototyping. In a rapid prototype, the idea is to build something quickly so we can learn from it. We know we're going to throw it away, or at least rewrite it, but (according to Brooks) that would happen even if we had written it slowly and carefully.

We know we're going to make mistakes in that first version. We might as well make those mistakes quickly.

A rapid prototype is an opportunity to make mistakes and to learn from those mistakes. The prototype should therefore focus on the parts you're least sure about, where you're most likely to make a mistake.

If I were prototyping a compiler, for example, I'd know how to build fast compile-time environments (aka symbol tables) using red-black trees or the shallow binding trick. So my prototype might use association lists to implement environments. That would be slow, but association lists are very easy to implement, they'll be fast enough to test the compiler on small programs, and I know how to fix the efficiency problem by using a more sophisticated data structure. Because there's no uncertainty about that, there's nothing to be learned by taking the time to implement fast compile-time environments in the prototype. It would delay the prototype for no good reason, and it would keep me from putting my effort into the more uncertain parts of the compiler, where I can actually hope to learn something from the prototype.

When designing your prototypes for the semester project, I urge you to focus on the parts you don't know how to do, or don't know how to do well.

There's a natural tendency to focus on things you can do well. For a prototype, that's counter-productive. If you already know how to do a good job on some part of the project, then you can take shortcuts on that part of the prototype. For the prototype, you should devote most of your time to the uncertain parts, where you need to explore alternative approaches or find out whether your chosen approach will work.

You should write your prototype to answer questions about your design. Respect the answers it gives you.

Sticking with something that doesn't work, or just barely works, is a really bad idea.