views:

597

answers:

16

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

A: 

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.

Lucas Jones
exactly why i know i should plan, yet i just want to code those ideas sometimes.
Tom Anderson
+20  A: 

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. :-)

MattK
Ah, yes, the "prototype", the one that will never see the light of day, right? ... Was that last smiley supposed to be a ;-) ?
Adam Bellaire
yeah no kidding, i already have 4 prototypes in production environment cause the boss said "just give them this one, it looks like it works"
Tom Anderson
The trick is to make sure the prototype doesn't look finished. Handdrawn graphics, ugly fonts... it's generally sufficient to reflect how the innards are not production-ready either.
Kena
Strike through text, buttons or links work too at discouraging "production" use.
pi
That is exactly what I do for years now. And it works perfectly.
Turing Complete
A: 

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.

Mark Brittingham
+2  A: 

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

Al W
+1  A: 

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.

John MacIntyre
+1 for edit, thanks for addressing the point :)
Tom Anderson
A: 

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.

Trent
+3  A: 

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

Paul Nathan
+1  A: 

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.

John Conrad
+5  A: 

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? ;)

Christian Nunciato
sending someone to staples...
Tom Anderson
A: 

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.

Marc Charbonneau
A: 

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.

felideon
A: 

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

Mike Dunlavey
A: 

Code away but use test driven development.

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

last thing i want to do in a "brain dump" is TDD tbh, brain dump coding is generally always going to be throw away code as it will be considered nasty throw away code.
Tom Anderson
+1  A: 

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.

Domchi
+1 - Nice to hear a response from the architect point of view, it goes to show that the more you write, the easier it becomes, unfortunately I am still a coder first, so I still have that nasty habit of wanting to just dive right in.
Tom Anderson
A: 

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.

RoadWarrior
gah, the thought of building that kind of website before coding makes me not even want to build a new product
Tom Anderson
That's probably a good thing. If your enthusiasm can't withstand writing a detailed sales pitch, then it probably wasn't justified.
RoadWarrior
it's not that, i would rather do the documentation than a sales site with e commerce, hell i would rather bury my head in the sand and let people play tether-ball with my legs.
Tom Anderson
So what's the point of a product where you can't write the sales pitch?
RoadWarrior
+1  A: 

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.

Bill K