Writing a crude implementation as part of the design - good idea?

Question

I am starting to fully understand the philosophy which claims that doing something, anything at all, is better than doing nothing, and advance will come from there.

So I am thinking something along these lines:

When approaching a new design (feature/module/component/whatever...) start off with creating a crude implementation with no pre-thought design, just do whatever comes to mind, fastest as possible. All this in order to achieve better understanding of the problem, even if all the work will go to waste because you figured how things should be.

Is there a programming methodology which advocates this philosophy? Do you personally prefer to just start coding a problem, or think long and hard before writing a single line of code?

Answer 1

I usually think on the problem for a while before-hand, so I at least have my algorithm planned out. Then I start writing and let the code take it from there. I find that without an overall idea of what I'm writing, though, it's hard to start, and I end up just wasting time.

Answer 2

There are definitely times where the approach you layout make sense. No sense sitting there with writers block over analyzing a problem...sometimes you just need to get something coded, and without a doubt as you work deeper into, and around, the problem, new ideas will help you refine your original idea.

You do need to be willing to occasionally rip things apart and start over based on what you have learned during your first stab at it, but I see nothing wrong with this approach. The risk would be that you never go back and re-do what you know you should. You need the personal motivation to re-do what is already been done - if you know you won't go back and re-do it, probably better to spend a bit more time in the design phase.

I suppose this approach may work better on a solo effort, or a small team than a big team with lots of contributors.

Answer 3

If you change "even if all the work will go to waste" to "knowing that all the work will go to waste" you're talking about prototyping. It isn't that you're not thinking about the problem, you just know that you want to solve it once before you solve it for all.

Answer 4

I generally don't write a line of code until I have a fairly good idea of what I'm doing.

UI mockups, though, I often design before firing up an editor.

Answer 5

Its not a bad idea, but one should always be wary of crude prototypes morphing into final code, but without the careful testing that such code should have....

Answer 6

This depends on the problem. For small and middle problems, I often start coding right away and start "really thinking about it" (stopping to code, grabbing some pen and paper etc.) in or between the process. For large and complex problems however, I take some time to draw a rough concept that outlines the possiblities, the possible problems, the different sub-problems and things like this and start coding later.

Another useful thing here is using unit tests before coding the functions you use there. They allow you to do kind of both. You start to code when you're still in the design phase and while coding the tests, you're actually using some of your later code and f.e. see what the problems with usage will be.

Answer 7

First, this is called a "spike" and people do it all the time.

Second, this is not a general approach -- it will not work for n00bz at all. Also, unless you inform management that you are merely creating a spike, you will cause more problems than you solve.

N00bz do need to create spikes. It's how they learn. But they can't create spikes for stuff that hasn't already been carefully designed. Until you have a fairly deep understanding of language, tools, architecture, data structure and algorithms, creating spikes instead of doing paper-and-pencil design is perilous.

The largest and darkest impediment to creating a spike as part of design is the schedule. If you're working on a project where the schedule is sacred, then you spike may be put into production because it appears -- to a schedule-obsessed manager -- to work.

Your spike can become a liability unless you label it a spike and intend to throw it all away when you've learned whatever lesson you needed to learn.

Answer 8

If you are in a team environment I think have a design reviewed by the team is a great idea before even writing a line of code. If you know nothing about the technology, interface, etc. in other words, you and the team has no idea if the design will work, then I say a proof of concept is I feel almost required before going into a detailed design. Going down a path where you "think" it will work until you actually try to implement that design is almost as bad as coding a solution with no design at all.

Answer 9

As far a method is concerned, I know that eXtreme Programming uses such a technique to explore unknown domain and calls it spike solution.

IMHO, this shall not be the preferred way to implement something ; it shall be used when you need to learn something, either about the domain, the environment, the tools ...

One risk is to report that the solution works and to have management requesting to ship as is. This is bas as such code is usually written without error handling, debug capabilities and so on.

It is sometimes interesting to implement it in a different language, possibly "easier" - read for instance a scripting language - than the desired language.

Answer 10

I'll add a nice quote I found on this link:

Spikes are good when you are knowledge-limited, not time-limited. -- KentBeck

Answer 11

I think it depends on where and how you're working. If it's a pet project or you're the sole developer, go nuts. Quite frequently I'll just bash my way through an implementation to see where the gotchas are - and there will always be a few.
If you're working on a team or you have management watching what you're doing, steer clear. Rather than see it as a quick prototype, they'll expect this is usable code and you'll likely feel pressure to keep it and keep developing it.

Answer 12

I find myself in the 'just start coding' mode when I am attempting something for the first time. You can read/research plan and design but you won't really know it works until you get something coded.

Recently, I created my first command-line app in VB.NET (Just never needed one before.). There were several pieces that I needed to see if I could get to work, so I wrote some code that evenually was completely rewritten. Once I got the questionalbe pieces to work, I started doing more planning & design on the full app.