Is it an inefficient workflow to write out code and THEN go back and optimize?

Question

I'm a newer enthusiast programmer. I've been doing small and big projects on and off for the past two or three years.

I always hit small snags in my code that add up to big memory hogs or unnecessary lines of code down the road. My philosophy on big projects has always been to just 'get it out of my head' and write all the code into a working product, then going back and reducing the code to a simpler, more optimized form. However, this doesn't always work: when doing database structures, I tend to have to go back many times to add in features that come up spur-of-the-moment. Entire blocks of code have to be erased because of a spontaneous brainchild.

My question to you is, is it more efficient to write an entire program and THEN go back and optimize it, or should I optimize code as I write it?

Answer 1

Premature optimization is the root of all evil.

That quote gets overused and applied beyond the original intended context, but the overall point certainly applies here: don't stop to optimize until you're sure you need to optimize it, and you won't be sure until after you've written most of the program.

Answer 2

is it more efficient to write an entire program and THEN go back and optimize it, or should I optimize code as I write it

Neither.

You're missing an entire huge component to the SDLC: design.

You should prove out concepts that you're unfamiliar with in a sandboxed environment (meaning it doesn't actually link in with the rest of your project, or if it does, it's easy to swap it out with something with a little more thought behind it).

Take the learnings from your prototype and write up a technical design. By now, you should have proven out any unknowns and figured out any potential small technical gotchas. The intent here is to fully flush out your design and make it as optimal as needed (refactoring for optimization while coding is a bad practice).

Then implement your design. There may be small oversights that you may have to account for, but by the time you start writing the code that will make its way into your main project, you will have your concept proven out (by prototyping) as well as an efficient design that accounts for as many edge cases as you and your peers can think of (technical design).

Answer 3

I will make you a counter proposal. Suppose you were to outline your classes first, whether this is through something like UML mocks, or simply class outlines it matters not, then, once you have determined what appears to be the best approach, begin writing. Once you have finished a noticeable portion of the project, then it is appropriate to go back and clean the cruft.

Depending on the scale of the project and the developer, this might be a set of classes, an individual class, or even (rarely) a method. But it is almost never a good idea to wait until everything is done to optimize. OTOH, it is also equally bad to optimize too soon. This leaves as the only option a process of writing and then cleaning, and writing and then cleaning.

Answer 4

In your case, it seems the best time to "optimize" depends on what you're doing.

If your code is very modular, fiddling with it later may not be very annoying, so it might be better to "optimize" later. If you depend a lot on your database schema, then fiddling with your database schema later may be annoying, so it may be better to "optimize" earlier.

("Optimize" is in quotes because I'm not so sure of what you mean by "optimize".)

Answer 5

Don't optimize at all until the running program tells you what needs optimizing.

Here's what I mean.

If we optimize without knowing what to optimize, we are a bit like the drunk looking for his keys.