How to prevent code rush?

Question

When you have an idea that is blazing through your head for a product, yet everything that is right with the world tells you to plan this application before jumping into a code rush, what methods do you use to prevent rushing to code?

---

From my experience planning software as apposed to building the software ad-hoc has always proven to be more successful by huge amounts. That itch though...

---

Methods thus far

• Rapid prototype it - could cause issues with boss wanting to deploy prototype.
• Don't code, design anyway - itchy itchy itchy...
• Get comfortable tools - itchy itchy itchy...
• User mind manager - not a bad idea, but still itchy
• Paper prototype - I like this one, recommendations for paper prototyping? Wall of stickies?

---

Curve Ball
Enterprise apps

Answer 1

I don't. I know I really should learn to stop, but since I only program for a hobby, I hardly ever design anything. Not that I can't, I just never want to. Funny how I never end up finishing a project.

Answer 2

Jump right in and prototype it. Then, once you've calmed down, take what you've learned from the prototype and design the real app. :-)

Answer 3

Well, a cold shower, obviously!

Seriously, I don't. I'll build a prototype with, at most, a few days of fleshing out in code. When I have some ideas down in code, I'll step back and see if the idea has legs. Oftentimes building the prototype kills the urge because it reveals the inner logic and/or less attractive aspects of the idea.

If the implementation path is straightforward and I still believe in the idea, then I'll add an appropriate testing framework and go for a second, more formalized rev that I can show some folks for feedback. Again, no more than two weeks of effort and often less.

From there, it dies or I'll start planning how to productize it. This includes a "vision" for the role of the product in our lineup, likely market position, etc. Once that is done, I have a good idea of what I want, a framework that includes some interface pages to demo, a business logic project and a testing project.

IMHO, creating a full spec ahead of time really doesn't help...especially if you think that you'll write one when you first get the flash of insight that drives you to approach the project.

Answer 4

If you have an itch, just scratch it. Let the code flow!

Answer 5

I also prefer to plan ahead of time.

But when you've got stuff "blazing through your head for a product", you can't code fast enough to implement it all. You want to capture it as fast as you can into some type of document. Then use that doc to do your detailed application design.

EDIT :

Paper prototype - I like this one, recommendations for paper prototyping?

I story board. Basically, I'll draw all the screens, and list all events the screen can have, along with what that event will do.

Answer 6

I am a fan of mind mapping tools for dumping my ideas. Sometimes I'll go as far as pseudo-coding parts of the app right in the mind-map, but at least there are no technical barriers that stop what is sort of a hybrid planning and design session, and the ideas can keep flowing.

Answer 7

I find a "evening" size chunk of the project and work on it to use that to review my thoughts on it.

Answer 8

I think it helps a lot to have a design tool or process that you are comfortable with and enjoy. If you are using a UML tool you have to struggle with, something that you have a hard time expressing your ideas with then the design process will not be something you look forward to.

Personally I like to sketch out my ideas with a pencil and a blank sheet of paper. I can draw diagrams, make notes, and easily erase and redo things as I come up with better ways for pieces to fit together. The process is not really important, the important thing is you find a process that you enjoy, because then you don't have to force yourself to follow it, it will just come naturally.

Answer 9

I start paper-prototyping, myself; I've learned (the hard way, many times) to avoid writing code until the code's somehow codified and makes sense on paper first. The urge is strong, though, you're right! Sometimes I do cave. But these days I find just sketching things out on paper, in increasingly granular detail (even technical things, schemas, UML diagrams, etc., although I usually begin with the UI and move backward), brings out the gotchas I'd encounter later in the process -- when it's more painful (and way less fun) to change them -- and makes me feel like I've made useful progress, scratching, if temporarily, the itch, as it were.

Good luck. Go out and buy some pencils and some unlined pages and get going, man! What are you waiting for? ;)

Answer 10

When I'm working on a new project I'll have to restrain myself a bit once I have enough on my plate to keep me busy. When you start building your data model, controllers, UI, and so on it's tempting to start putting in the really fun new features so you can see how everything works together. The problem with this is that you end up with a lot of code that's only 80% complete, and that last 20% is the really hard stuff. Instead, work out enough to implement some bare functionality, or start just enough of the application where you can keep everything in your head at once, and really get that portion working well before moving on to new things.

Answer 11

Prototyping sounds like a good idea, like MattK mentioned. However, if you can break down the project into separate functionality, you can create small test projects to try out your ideas.

Once you have the functionality ironed out, throw away the test projects. You'll be sure to write cleaner code when implementing those ideas in the real solution.

Answer 12

I agree, let the code flow. Just be willing to throw it away.

Answer 13

Code away but use test driven development.

Writing the unit tests help refine and clarify the actual requirements.

Answer 14

What methods do I use to prevent rushing to code? Hell, I feel lucky if I find enough time in the next week to even open my IDE with the idea of coding something new! Even at work, because of my architect-not-coder position, I get quite enough time to think the idea through, since thinking is easy. Coding new functionality (as opposed to improving existing code and adding small features), on the other hand, requires concentration and uninterrupted periods of time, where I need to have peace of mind, which happens only if I don't have anything "pending" for that day.

When I code something new, I tend to have all details in my head and think about nothing else; designing and thinking about something, on the other hand, I can do even half-alive after a long and bad day.

As to answer to your question... :) ...I tend to write what I think about a lot, and then later go through my notes, organize them, and once I do get to the coding part, I usually have to-do list broken down to tasks. If I don't, I create it, since I can't code if I don't have the whole thing loaded in my mind, and breaking things down to simple components is just that - loading a project in my short-term memory.

Answer 15

First force yourself to write the website that's going to sell your product.

This makes you think about exactly how the customers are going to benefit from your product. It also forces you to prioritise the features behind the benefits. Finally, all that writing is a good way of bringing you back to reality.

Answer 16

Chances are you are itching to go because you have something you aren't certain about--a new design, process or theory you're wanting to try.

Those should be prototyped. In parallel, get some design down on paper. Go back and forth, but target having your design done before you're totally committed to any of your code, consider it prototype until then.