64Digits

On Restarting

Posted by DaSpirit on Jan. 2, 2014, 8:22 p.m.

So, recently I've pretty much restarted on my IDE project. This got me thinking about restarting on other projects. Some reflections and tips about restarting projects:

Don't

Let's face it. It is a boring task. You have something working and you destroy it. Work on getting your game to work. What is a game if there are no mechanics?

And Optimizing?

Optimizing is also a waste of time. Don’t do it unless you either see lag or you’re already finished with your game, with the latter always being a priority over the former. Some programmers focus too much on getting things perfect. It’s funny, because these are also the programmers that have never finished anything (myself included). It’s a trap, do not fall into it. Also, be careful of early optimizations.

What About Organizing?

Organizing is indeed another time waster, and should not be done unless you are working with a team. It works as long as you know where everything is and you do not need to move stuff around if so.

What To Do If I Do Rewrite?

There are a few times where a rewrite is useful. Try to keep as much old stuff as possible. Rewrite around everything. DO NOT delete anything. Just make classes that serve to replace existing ones and slowly give them new functionality.

Anyway, I hope this small blog helps anyone, especially with F4D currently going on. I am forced to rewrite because I had to change a major class because of my plugin framework (should have done research on that earlier). I’ve fallen a victim to rewriting in all my projects. Remember, chaos is expected, this is the law of entropy. If you’ve dealt with the chaos before attempting to rewrite, you can surely deal with it some more.

Comments

colseed 10 years, 10 months ago

Quote:

Optimizing is also a waste of time.

Organizing is indeed another time waster

Try to keep as much old stuff as possible.

i…i guess i can see how that's tr-

Quote:

chaos is expected, this is the law of entropy

KaBob799 10 years, 10 months ago

This is exactly why 64d has never been finished =p

Quietus 10 years, 10 months ago

i love how colseed still feels the need to supply us with migraine-inducing gifs even though he knows to hide them.

and anyway, this all depends on what timeframe you're working in, imo. having lost this whole week i could've spent developing, i'm not so focused on optimization anymore so much as just presentation.

eagly 10 years, 10 months ago

Uhm, this all seems like bad advice to me. A project should only be restarted if absolutely necessary, yes. However, the other things you mention are both completely unrelated to restarting a project and are incredibly important!

Quote:

. I am forced to rewrite because I had to change a major class because of my plugin framework (should have done research on that earlier).

Surely this should tell you that planning is important and necessary. If you take the time to properly design and plan your system, you'll make your coding task a hell of a lot easier, as you'll already have a set structure and a very clear idea on the classes you'll need and their relationships with eachother.

Optimising is not a waste of time. Agreed, in the early stages it's not as important to think about. BUT it comes back to planning and organising. If you think about how you will implement something before doing it, you will more often than not make optimisation in the future much easier.

So DO organise and plan and design and then optimise where possible as you go along. Use debuggers and profilers to pinpoint functions that take much longer than they should and locate memory leaks. Don't dismiss these areas of the development cycle!

Castypher 10 years, 10 months ago

Quote:

i love how colseed still feels the need to supply us with migraine-inducing gifs even though he knows to hide them.

He hides them from you. Nobody else cares about them as much as you do. If it bothers you so much, stop opening his hide tags. Complaining about things you have complete control over gets you nowhere.

Also, I don't necessarily agree with your points, DaSpirit. If something is inherently flawed, why continue building on trash? In many cases, it can be much more beneficial to restart the project with a different approach. Sure it doesn't help you finish any faster, but it'll (hopefully) make it that much higher quality.

Now, if your argument were against scrapping things entirely, I'd agree with you. Even with my old, shitty novels, I still keep them around because there are a few gems in that pile of shit, and it's fun to see how far I've come since I first began. I discovered in one of my larger projects that I wholeheartedly regret even deleting my notes for it. I would kill to have those again. Keep old stuff somewhere.

And regarding optimization, I wouldn't discard it entirely. That's poor advice. However, taking focus off of optimization when optimization isn't needed is acceptable. That's actually the issue I have with a lot of programmers I know. They put so much time and effort into making something run as fast as possible when the optimizations are absolutely minimal. Incidentally, they never finish their projects either, because they spent so much time making minor changes that nobody but them would ever notice.

Powerful Kyurem 10 years, 10 months ago

DaSpirit: Virtually everything except restarting, is part of normal programming. If I don't get it right or organize it, how am I going to work with it easily. Optimization usually condenses code.

DaSpirit 10 years, 10 months ago

Quote: eagly

Surely this should tell you that planning is important and necessary.

Of course, I've done planning. My issue turned out to be with different compilers. My code was fine and worked. It's just if I wanted to be compatible with multiple compilers, I had to rewrite a few classes to support them. My framework was pretty complete, and I have not deleted most of it.

Quote: eagly

[So DO organise and plan and design and then optimise where possible as you go along. Use debuggers and profilers to pinpoint functions that take much longer than they should and locate memory leaks. Don't dismiss these areas of the development cycle! /quote]

It is important, yes, but I have seen people who write 10 minutes of code and then spend a few days comparing that small code with different compiler settings. Honestly, it's things like these that should be avoided until the very end, where it starts making a big difference. Debuggers are very important during development, and I have not dismissed the idea of at least profiling. I highly recommend Valgrind and I use it myself regularly. However, it is mostly to see if anything needs fixing early on, in case it becomes a larger issue later. It's part of planning for myself. If I am unsure about anything, that's where I go to make my decisions.

Optimizations are important. My advice was more against constant optimization. I don't think you should write code thinking you can optimize later, that optimization is still rather necessary. It's just looking at the same function for a week that is poor practice. Unless you're writing a compiler, it's not a big deal.

eagly 10 years, 10 months ago

Ah, well in that case, no, you don't need to minimise your code and get 0.0000001ms speed ups. :p

But like I say, if you plan something properly, it probably won't need much optimisation.

Toast 10 years, 10 months ago

Optimising confuses me because I have no idea what the compiler does to stuff or how operators actually work.

e.g. Is there any advantage to writing if(x&0x8000) instead of if(x>=0x8000). No idea.

Powerful Kyurem 10 years, 10 months ago

Toast: Not sure. Usually, other than eliminating steps, optimized code does the same thing. It is just smaller.