Where can I find the/What are the correct steps/strategy to plan before coding? [closed]

Question

I know how to code and get things done but almost all the time it takes me too much time to create a first working version of the algorithm/application.

I start from one part and then jump to another and then realize I need something else and jump to another part.

I think I lack on the planing part and dividing the goal into small goals\parts.

How do you tackle a new software project? What advice can you give me about planning and dividing the problem? Or maybe this is not the problem and you have something else to suggest me in order to solve this thing?

If you have good reference material to link to as well so I can continue reading/learning about it.

Answer 1

The first step is to decide what you want your program to do. Make a detailed list of the functionality you wish your program to have. And once you've decided, avoid adding anything new halfway through implementation. If you design your code correctly, you should be able to add new features with relative ease afterwards.

Decide who is using your program, and how they'll interact with it. Is it a specific client you're designing it for? In that case you can afford to specialize the program design to your clients preferences. Are you designing it for a massive audience? In that case you'll want it to be more customizable, yet simplistic. You'll also want to put more thought into appearance. will the users be interacting with a server? If so you'll want to design your program to be scalable.

Decide on how you intend to design the program. Will your program be event driven? If so will you be using an event polling system, or will you have event handlers? If your program needs to be scalable, does your design allow for runtime improvements without massive downtime? will you be able to easily improve the runtime performance without massive rewrites? Think deeply about design choice because if you don't it can result in having to restart from scratch.

After all of that is out of the way, start thinking about how you will structure your code. This is an entire process all its own, so I won't go in depth, I'll just point out a few things to avoid.

1) Do not use interfaces/abstract classes if you do not need to. They are not magical features that should be used at every opportunity, contrary to what people say. They can lead to massive reimplementation problems, and poor design.

2) don't overuse inheritance either. For the same reason stated above.

3) don't over design your code. You don't need everything being as fast as possible if all you're doing is sorting a small container with 30 elements. You don't need to make everything as abstract as possible either. If the benefits can't be observed either through performance, or code readability/maintainability, it isn't worth the effort.

4) make sure to make your code modular when possible. It'll make adding or removing features in the future much easier.

That's some basic tips I can offer you.

Answer 2

You pretty much identified your problem here and are on the right track.

As mentioned in Imnota4's answer nothing will beat a bit of planning. Pen and paper (or whiteboard or whatever float's your boat) is your friend here. Goal here is not to write a detailed spec of the software, it's incredibly hard to get right from the get go. I wonder if i's even possible for more than the most trivial software. You just want to get the chaos out of your head and try to organize it a bit before you start. Think of dumping a bucket of Lego and start sorting them, not all of them, just enough to get started.

• What is the problem you try to solve, write it down. Few lines, never more than half a page. Don’t dive in details on How's and the Who's, just focus on the What and the Why's. It's easy to loose sight of it when down in the trenches. This will be your beacon that will keep you on point.

• What is the data. Data is the heart of your software, has to be. Identify all the pieces of data and lay them out, note their relationship, what needs to change in the data. Model it well, usually if you nailed how the data is the rest becomes much easier. If at a later time you find something is just too hard to code, that you can't figure out how to get it done, come back to how you modeled your data, most likely there is something you did not anticipate or forgot to model.

• How is it going to be used ? Write down the interactions the users will have with your software. Separate them in small stories, then group your stories together by how closely they are related. Keep the stories small, most of them will be trivial. It's not a single story that describes the system but the sum of them all. Don’t worry if you get them all right away though, at first focus on the obvious, you will add more later as you advance.

Now you are ready to start coding!

On most of the stories you should already have an idea on how you will code it, but often some of them will make you feel a bit queasier. At this point I tend to pick the one that I find the worst and pick around in a block of monolithic code in a scratch pad main function somewhere. I'll hack at it until the uncertainty is brought down to a more comfortable level and I get a pretty good sense on how I’ll get it done.

Now I start. I pick a story, implement the data part this story needs (and not much more) and start coding. Start with shells, write tests around them to make sure the story holds out and code it till it passes tests.

As much as possible I try to hold myself from anticipating, rather I refactor when needed as I implement more and more of the stories. It's quite common that the first part I wrote get re-written 2, 3, 10 times even, it all depends on the complexity and how well the problem was broken down in the beginning. I find that if I do anticipate future needs by implementing it now, rather than save time, I end up having to refactor anyways and now I just have more stuff to think about. Often times what I thought I needed turns out completely useless as I figured a smarter way to get it done.

Hope this helps