The Enterprise

The use of prototyping

Michael Pankov •

I recently watched a remarkably fun and motivating talk on software engineering, engineering in general, and history of humankind space exploration. It's called "To the moon" and you should absolutely watch it, if you're interested in at least one of the three topics.

The thing that I found particularly interesting is that when doing a project, especially a big one, you should start with simplest thing possible (the link is to the specific point in the talk).

The crux is this: one should start with something simple to the point of being silly, and the harder the project, the sillier your first task should be.

Why is that? Because we often overestimate our abilities. We underestimate unknown obstacles. The larger the project, the more costly it will be to overcome the obstacles later — when we've already built something based on the assumption, which may not hold. We don't know, because we didn't test it.

So test it. Test your every assumption in quickest way available, and throw the prototype out of the window.

The "throwing out of the window part" is also (if not more) important, than the first one. Because once we aim for speed, we don't aim for code quality. And for prototype, we shouldn't aim for quality — it's only needed to check if it's a good idea in principle. The final design will be a compromise of various factors (including the time limits and required quality of code), and it should be done differently than the initial attempt at understanding the problem domain.

This is the idea behind "hello world" programs. A newly coming developer may assume all the infrastructure will work, and start writing some actual program. Just to discover that they miss required libraries on development machine, that their editor messes up the source file encoding, or that the tutorial one reads is based on newer version of the language, than they have.

These are all petty problems. But they add up, and in case you're testing some actual code that does the job, it will have it's own, not-so-petty mistakes. They will overwhelm and demotivate you. Don't let that happen.

When starting to learn a new programming language, write a "hello world".

When starting a Moon program, launch a rocket and crash it on the surface of the Earth's satellite.

When starting a new task, test every thing that you think you're sure in, first.
comments powered by Disqus