Rapid Prototyping Rule #1

by George on Sep.22, 2009, under Coding

Everything is global. Everything is public. Everything.

In code that will never see production, and shouldn’t have a life span of more than a week or two, ‘proper’ encapsulation is pointless. Fight your inner software engineer and focus on the goal at hand, which is testing an idea as quickly as possible.

Share with friends:

:Rapid Prototyping

4 Comments for this entry

Noel
September 22nd, 2009 on 9:56 am
Agreed. But frankly, once I started doing that, I realized that there wasn’t much point to having private members even in production code. Not usually anyway (no smiley there, I’m totally serious).

Reply
Sam
September 22nd, 2009 on 10:25 am
Is that just for when you are a lone programmer, or in general? Seems a bit dangerous if you are letting joe blogs in the next office use it.

Reply
Noel
September 22nd, 2009 on 3:24 pm
I’ve gotten away from doing “defensive” programming. I write code for myself or other programmers with similar experience. No point in writing code for possible situations in the future that might or might not happen. And defensive coding takes extra effort to write and gets in the way of fast refactoring.

Now, if I was writing code that was going to be actively worked on by a bunch of junior programmers I had no control over, then that might be a different story.

Reply
Jeff
September 22nd, 2009 on 6:04 pm
I think that is a safe enough plan for small projects, where the whole project architecture can fit in the brain.

For larger projects, encapsulation and other “defensive” methods are very important. Even when working with veterans, programmers cannot read each others minds, and may not understand the intent of their comrades.

And of course, when a programmer has to revisit a piece of code they wrote several years ago, they have became the “joe blogs in the next office”.

Reply