New answers tagged

1

The first question you should ask yourself is "how bad is the flaw?" What exactly did you do wrong? If something is so bad that you will waste tons of hours trying to work with the issue, exposes sensitive data (passwords/credit-cards), or causes a bad vulnerability, then maybe you should edit it, but most of the time you can take what you have, finish it ...


0

It depends on how messed up your code is. If you made real n00b errors which make your code overly complex or verbose, then I would recommend to rewrite those parts. If you think you have serious bugs which you'll have to fix anyway, then write some unit tests that can check whether you've fixed the bug (...since you can't yet launch the program). It's ...


1

If your code is modular then you should be able to finish the rest of the code around the badly-written components then re-write the badly-written components without affecting the rest of the code. In that case, it's up to you when you re-write the badly-written components. If the badly-written components are so badly written that the finished code won't ...


2

The answer depends on something which I like to call the "complexity ceiling". As you add more and more to a codebase, there is a tendency for it to become more and more complex and less and less organized. At some point, you will hit a "complexity ceiling", at which point forward progress becomes very difficult. Rather than trying to keep moving by brute ...


5

Refactor. Refactor. Refactor! REFACTOR!!!! Honestly, no matter how experienced you are this is a common problem. You wrote code, you learned something, and you want to use the new knowledge on the old code. You want to measure the old code against the new knowledge. That just won't work. If you do that your application/game will never be completed. Instead,...


2

Just to add some of my past experience into the mix. I have been working on a side project for over a year now, whenever I get a spare few minutes. This project went from a simple testbed to a static class to a object orientated slim lined design it is at now. Throughout all of these changes I have kept the same functionality of the code, excluding bug ...


2

You have to put yourself in the employers shoes. To most recruiters, you'd be the most valuable if you go this way : - Finish it off with 100% tests on the new code you write. - Add tests for the old (bad designed) code. - Refactor it to achieve what you wanted as a design. Do all that with a good versioning process, branches and tags. Rewriting is ...


3

I'd say it depends a bit on what kind of code you have now and where exactly the problems lie. I.e., if your foundations are good (proper class design in the most parts, good decoupling/cohesion etc., just a few bad choices like the threads you mentioned), then by all means get a bare-bones 1.0 out and then refactor like there's no tomorrow. On the other ...


8

You lost me at this sentence: The problem is that I have not finished even the main functionality of my program, so I cannot truly refactor, and I feel discouraged to go on perfectly aware that my code's design is flawed. I believe in the principle (stated in Systemantics) that A complex system that works is invariably found to have evolved from ...


11

I would respectfully disagree with suggestions that rewrite is a bad idea. In the realm of software life cycle, it is generally accepted that the time and effort required to correct an error increases by an order of magnitude each layer in the life cycle. That is, if it takes 1 hour to correct an error at the requirements level, it will take 10 hours in ...


6

One of the problems you are facing when running into a problem like this, is you are emotionally attached to the code you have written so far in some way or another. A colleague told me he was writing a program while in university while he got lessons from a famous professor ( i believe it was Dijkstra). He asked the professor to have look at the code he ...


30

You're probably still in the "learning fast" part of your development. There's a good chance that a few months from now, you'll find that your new and awesome design is horribly broken in ways you weren't even aware of when you started. Get things done - this is the single most important thing you need to learn. Believe me, I know plenty of people (not just ...


1

Neither? Both? Continue onwards, spend some time on revising the existing design and some time adding new functionality. If you have racy interactions, that might be a good place to start ("excessive threads in renderer" sounds like an inefficiency, rather than something that would cause correctness issues). See if you can figure out either a general way ...


5

It sounds like your skills have grown substantially in that time period. Perhaps working on that project contributed to it. Designing it again as a purposful learning experience would be fruitful. Remember, this isn't something you need to deliver as a working program for a customer. It was written specifically for the practice. So, unless you want to ...


18

Restarting from scratch is usually a bad move in real life projects, mainly because real life projects accumulate bug fixes that a newcoming developer is not aware of (e.g., see Things You Should Never Do, from Joel on Software blog.) Neverthless, school projects don't inherit such history and usually start by coding and designing at the same time with ...


22

Rewrite it. Non-working code has little value, and three thousand lines is not much code. It won't take nearly as long as it took to write the code you currently have, and it will be much better. I have often thrown out five hundred or a thousand lines of poor code, and often the rewrite is one-fifth as long. Most of the notions around "don't rewrite" ...


22

I follow the "Make it Work, Make it Right, Make it Fast" ideology in software development. Make it Work: Write the core functionality, so that the project is usable. Do what you have to in order to make everything work, even if it means ugly code. Make it Right: Fix bugs and refactor the code so that it is easier to read, understand, and maintain. Make it ...


232

If I were in your shoes, I would probably try it this way: first, finish the current project - at least partially - as soon as possible, but in a working state. Probably you need to reduce your original goals, think about the minimum functionality you really need to see in "version 1.0". then, and only then think about a rewrite from scratch (lets call ...


106

Finished IT projects, even faulty ones, are much better than unfinished ones. Unfinished ones can teach you a lot too, but not as much as finished ones. You may not see it now, but you get an enormous amount of value working with even faulty code. My vote goes for finishing and then, maybe, refactoring - if needed. When you start working with more ...


52

I would happily start the project over. You're a student, and you're still learning. This puts you in a very different position than the question you linked to. You have no professional responsibility for your code; if you were to delete the whole project right now and walk away, you would suffer no repercussions. This is a huge advantage for a ...



Top 50 recent answers are included