This article is a preview of my January 22nd talk at Charlottesvilles Neon Guild where Ill be talking about my experiences with rapid prototyping. If youre local, Id love to see you at the meeting and hear your thoughts!
Theres a time to stop and be finicky about code. A time to chose the best idioms and design patterns; think deeply about how classes relate to one-another. This is the code we know we want to keep. Its tied to a proven product and we need to act with care.
Theres also a time when code quality doesnt matter. This happens when we prototype. When we explore the problem space, its likely that large parts of the initial vision will be thrown out or reworked. Its not worth perfecting code that will get discarded or replaced.
Its important to keep this difference in mind because often we Software Engineers fill the role of holy defenders of software quality. In our day jobs, we work on mature products – pieces of software that need to be carefully tended like a garden. Theres a general mild defensiveness(paranoia?) against changes that may hurt software quality. Theres always a “them” that want to get something big/crazy done within a crazy aggressive schedule that may threaten our carefully tended garden.
While this attitude helps us in our day job, it doesnt help us when slinging around new ideas.
Instead, the challenge is to work directly against our nature. We need to write dumb, naive code – the dumbest most naive and horribly basic code that shows off our idea. Let it crash and perform poorly and flounder. Ignore those exceptions that are certainly going to happen in certain cases. That only gives you an excuse to remind everyone that what youre doing is a prototype and not a product.
Because, without a quick, direct path to feedback you might be taking a long road to nowhere. Remember the goal is to fail early and often. Your goal isnt to build a robust application, its to build the simplest end-to-end expression of your idea that you can. You want to show what youre thinking at the earliest opportunity to get feedback. Finding the deficiencies in your grand idea with your time is far more crucial to your success than perfecting the implementation.
So dont dig holes that youll only have to fill in again. Spend some time and reflect on where you are keeping your code quality dial. Are you working on proven, carefully tended code or are you trying to test new ideas? Or maybe youre somewhere in between? Wherever you are tune your code-ometer accordingly, being careful to invest no more and no less than you need to in the code youre writing.