Is it a good idea to write a rough implementation within the design?
I am beginning to fully understand the philosophy that doing something, anything at all, is better than doing nothing, and progress will come from there.
So, I am thinking something like this:
When approaching a new design (feature / module / component / whatever ...) start by creating a rough implementation without prior design, just do whatever comes to mind as quickly as possible. All this in order to better understand the problem, even if all the work goes to waste, because you understand how everything should be.
Is there a programming methodology that defends this philosophy? Do you personally prefer to just start coding the problem, or think long and hard before writing a single line of code?
a source to share
There are certain times when the approach you are using makes sense. There is no point in sitting there when writers are blocking analysis of a problem ... sometimes you just need to code something, and no doubt, as you work deeper on the problem, new ideas will help you refine your original idea.
You need to be willing to rip things up sometimes and start with what you learned during your first punch, but I don't see anything wrong with this approach. The risk is that you never come back and do what you know. You need personal motivation to re-do what has already been done - if you know you won't come back and do it, it might be better to spend a little more time in the design phase.
My guess is that this approach may work better for a solo effort or small team than for a large team with a lot of participants.
a source to share
It depends on the problem. For small to medium sized problems, I often start coding right away and start "really thinking about it" (stopping to code, grab a pen and paper, etc.) during or in between. However, for large and complex tasks, I take some time to draw a rough concept that describes possible problems, possible problems, various sub-tasks and the like and starts coding later.
Another useful thing is to use unit tests before coding the functions you use there. They allow you to do both. You start coding when you are still in the design phase, and when coding your tests, you are actually using some of your later versions of the code, and fe that use problems will be.
a source to share
First, it's called a "splash" and people do it all the time.
Secondly, this is not a general approach - it doesn't work at all for the n00bz. Also, if you don't tell the management that you are just creating a thorn, you will cause more problems than you solve.
N00bz needs to create spikes. This is how they learn. But they cannot create thorns for things that have not yet been carefully designed. Unless you have a deep enough understanding of the language, tools, architecture, data structure, and algorithms, making peaks rather than making a paper-and-pencil design is dangerous.
The biggest and darkest obstacle to creating a splash as part of a design is a schedule . If you are working on a project where the schedule is sacred, then you can put the splash in motion because it appears to work with the graphical manager.
Your thorn can become a liability if you don't mark its spike and are determined to throw it all away when you know what lesson you need to learn.
a source to share
I get into "just start coding" mode when I first try to do something. You can read / research the outline and design, but you won't know it works until you get something coded.
I recently created the first command line app in VB.NET (just never needed before). There were a few parts that I needed to see if I could work, so I wrote some code that was completely rewritten. After I got the assignments to work, I started doing more planning and design in the full app.
a source to share
If you are in a team environment, I think the design reviewed by the team is a great idea before even writing a line of code. If you don’t know anything about technology, interface, etc., in other words, you and the team don’t know if the project will work, then I say that I feel a proof-of-concept almost necessary before getting into the detailed design. Going down the path where you "think" it will work until you actually try to implement that design almost as badly as coding a solution with no design at all.
a source to share
As I understand it, I know that eXtreme Programming uses this method to explore an unknown domain and calls it spike solution .
IMHO, this would not be the preferred way to implement anything; it should be used when you need to learn something about domain, environment, tools ...
One of the risks is to communicate that the solution works and have controls that need to be sent as is. This is bass since such code is usually written without error handling, debugging, etc.
Sometimes it is interesting to implement it in another language, perhaps "easier" - read, for example, a scripting language - than the desired language.
a source to share
I guess it depends on where and how you work. If this is a pet project or you are the sole developer, go nuts. Quite often I just bash through the implementation to see where the gotchas are, and there will always be a few.
If you work in a team or have control over what you do, stay away. Rather than seeing this as a quick prototype, they expect it to be useful code and you will likely feel pressured to keep it and keep developing it.
a source to share