This article is a preview of my January 22nd talk at Charlottesville’s Neon Guild where I’ll be talking about my experiences with rapid prototyping. If you’re local, I’d love to see you at the meeting and hear your thoughts!
There’s 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. It’s tied to a proven product and we need to act with care.
There’s also a time when code quality doesn’t 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. There’s a general mild defensiveness(paranoia?) against changes that may hurt software quality. There’s 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 doesn’t 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 you’re 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 isn’t 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 you’re 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 don’t dig holes that you’ll 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 you’re 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 you’re writing.