[/caption]Sometimes, there's no substitute for actually trying something out. A prototype is a 'quick-and-dirty' piece of code in which you try out possible solutions to some (or all) of your requirements. In this article, we're going to consider the whens, whys and hows of using prototypes in your software project.
Trying it out...
Your goal in writing a prototype is to explore how to solve a particular problem(s) before writing the proper code. It's a trial run. The point here is that your first attempt will be made when you've got no experience of how to solve a problem(s). You may suffer for your lack of experience but you'll learn a lot from the experience of the first attempt, so a second attempt may well produce a much better result. A prototype is that first attempt.
A prototype gives you the chance to try out different ways of meeting the project's objectives. Perhaps you can think of more than one approach and you'd like to test which one's best. Or maybe you start off with one idea but think of a better one as you're writing your code. During the prototyping stage, you can try these options and decide on which one will be the best solution.
When to prototype
When might you consider a prototype? You want to write a prototype when a solution is not clear; when there are several approaches you could take, but none stand out; or maybe you're worried there may be no good solutions and think it's a good idea to experiment for a bit before committing to writing the whole program. It could also simply be the case that you would like to get a bit more experience trying to implement this kind of program before having a go for real.
'Quick-and-dirty'
Because a prototype is only exploratory, reckless coding is okay (note that this is probably the only case where we'll say that). This is specifically because the point of a prototype is to learn, not to become part of the final program (this is important!). Your aim with a prototype is to learn from it as quickly as possible, so you can move on to writing the code for real. This will mean you write quick-and-dirty code (no validation, no testing, code focused on a single idea, not caring about efficiency etc.). This is fine, but it does mean that it's throw-away code. Don't be tempted to include it, or parts of it, in the proper code you write. This would be a mistake because when writing the prototype, you've sacrificed quality for speed. The proper code must be reliable and easy to work with, which means it must be separate.
You need to strike a balance here. Speed in prototyping is a good thing because you want to gain the experience and don't care as much about writing character-perfect code. But at the same time, you need to consider what you're writing so that you can learn from the experience, as well as producing valid solutions.
Now, throw it away!
Now that you've finished your prototype, throw it away. No, seriously. Your prototype has hopefully been a wonderful learning experience, but as far as being high-quality, well-crafted code goes, it is junk. We know it's tempting to keep using the prototype, after all it seems to work, but it's a horrible false economy. Not only are there likely to be bugs in the prototype code (quick-and-dirty, remember?), but the whole point of a making prototype is so that you can do a better job with the proper version of the code! It will even likely be the case that the time you "save" by keeping the prototype gets wiped out (and more) by the extra hassles caused by using inferior code. Don't do it!
Once you've finished your prototype (and thrown it away), you should hopefully have gained greater insight into the problem you're trying to solve. Now all you have to do is incorporate this greater insight into your plan. Because right now your project is just a plan, as opposed to a plan + code + documentation, it's relatively easy to change. So, do so. Use your new insight to improve your plan. It's even possible you may realise you want to adjust your requirements. In extreme cases, your objectives may even change (for example, if you've discovered you can't meet one of them because the run-time will simply be too long). Take the time to make these changes/improvements. Then see if you need any new prototypes.
Prototyping some or all of your project before you write the code 'for real' is a great way of understanding the task properly, as well as trying out some ideas to find the best solution for your project. It's an investment of time, but time well spent!
I really like this article. It clearly explained the meaning of prototype quality code.
ReplyDelete