How many rebuilds before you'll abandon a project?

Question

I've been working on a project for well over a year now and have a functional version already released, but for a few months I've been trying to work on major upgrades & making it more stable. At some point I realized how nice it would be to have a library to help simplify most of the work and so for the last month or two that's been my focus.

I'm on about the 6th *complete* rebuild from scratch now and about to say screw this and abandon everything and just quit coding for a while....

What's your limit?

Answer 1

Is a personal project or business project? Some times there are good business cases for rebuilding a project from scratch, so get more rebuilds than a personal​ project. I have rebuilt significant parts personal projects lots.
Only 1 time I rebuilt the whole project from scratch, I changed the underlying algorithm, I have it a lot more functionally (almost​ a completely different project), and I changed the language it was implemented in.

I would suggest only rebuilding a project from scratch if you learned a lot from building previous version, and can see there is a better way to do it. Otherwise improve the code you have. This will depend on the project.

Answer 2

I just go on for as long as the project makes sense to me. But taking a break is important, even if you won’t abandon the whole thing.

Answer 3

@Pedro -- Yeah, that's how I am too, and why I haven't given up on this one yet. Lol.

@Jared -- It's actually a personal project, but it's going to be a public API/library and I'd like to do it as professionally as I can. So stability, maintainability, and usability are my main concerns, and I plan to do full documentation along with testing + coverage reporting and examples.

Using TDD I've gotten the latest version that I started writing after posting this beginning to work, but much of it still needs to be implemented again so it's really only the skeleton of the library. Lol. It does work around the previous issues though, so I guess I did learn something (surprisingly).

Answer 4

TDD is a good approach for a big project. Sounds like you know what you are doing. What are you trying to achieve with your API/library? Are you planning to make it open or closed source?

Answer 5

It's meant to help load/modify/save the configuration data of another program which doesn't manage that well by itself (Steam). I've already released an app that does part of this, but just built the functionality into part of the program and it would need to be tweaked a lot to be of any use to another person's program, and does not support some things like attaching user-specific data to the user's themselves which means users have to be loaded each time they are selected in the app.

It's actually a pretty small library so far -- 300 lines for the main script + 200 for a utility script with functions the main script only uses one of, but the examples will use the others + 200 lines for the test script. There are still a few methods missing, but so far it's functioning properly, the error handling seems to be working properly, and it can load everything that it needs in about a second (one file takes about 700-850 milliseconds because it's huge + binary so it needs to be parsed specially).

I have considered/designed another class for the settings data to help keep it within limitations, but haven't built it (for this iteration of the code) yet. It's not 100% necessary, but is very useful because in the settings data they do most things at least 2 different ways along with using a terrible naming convention and using 8 files + anywhere between 2 and unlimited folders for the configuration data (unlimited because users can add additional folders to install apps to even though it's only useful to have one per drive).

It will be open-sourced and publicly available on GitHub and through NPM, and I plan to use it in the next version of my program to power a lot more functionality including backing up/modifying/restoring settings without overwriting important data, auto-categorizing games in a user's library, and more; not much more though, simply because there's really not much more to do. Lol.

Answer 6

Well that explains at least one rewrite, going from a specific solution to a general solution.
I would suggest thinking all the functionally you will need and how it will work together. Just from a big picture point of view, not all details until you get to then. TDD can lead to quite large code refactoring.

Answer 7

Yeah, I've been trying to do that the whole time; initially it was just one big kludge for the proof-of-concept version; then while rebuilding I forgot about how messed up multiple user support would be which caused another rebuild, and then I rediscovered getters/setters and wanted to use them to protect parts of the data but I did that all wrong so that version got scrapped...lmao.

But yeah, I've seen what you mean a few times already since I started the TDD style -- I spent much of last night rebuilding the path handling to support everything it needs, and now today within about 2 hours I built a much better class + tests for it that now needs to replace that garbage I setup last night. Lol.

I really suck a lot at the design part, though I do understand the flow diagrams & etc. I've tried to use them, but it's never went very well, so I just went back to what is basically the "throw code at it and see what works" style, though of course I try to get some idea of what to do and work it out on paper/a note before writing the code.

Answer 8

As unhelpful as it may sound sometimes you just have to write more code. Working out the best way to implement the solution comes with experience. Even then you will still have those times when you think "I should have done it that way instead." The more code you write the better the quality of your code. Also you should get better at writing code that's easy to modify.
It may help working on a project with a group, as this will encourage you have a plan and stick it.