There’s a question I often ask to myself, so I finally ask it to the wild.
When a project becomes large and the programmer [starts to] understands he made something inappropriate since the beginning (speaking about non-professional projects which may have been started with some guesses), there are often 2 choices:
try to fix the current project
start a new one from scratch
I’m in such a situation with several of my projects, trying to fix things on the stack of a bad design choice, up to the point where continuing to fix things barely make any sense.
On the other hand, those are complex projects: re-creating them from scratch, omitting the bad design choice (i.e. redoing it with a different logic) would take some times (Days? Weeks? Months?) when I already have an app, buggy, for the same purpose; I may as well use the buggy apps and accept their flaws.
Both solutions look rather expensive to me. Does a fixed answer even exist?
What would you think?
take the opportunity of making a new program, and make choices that don’t go bad, knowing what went bad with the other projects.
then when you’re satisfied with it, modify the old project to use the new project architecture
with xojo refactoring tools , and external items, it’s a quite easy task.
but yes it takes time.
While I know what went bad, there’s always the possibility that a new approach may go bad otherwise. An endless loop of restarting from scratch, maybe. But, well, your advice helps me choosing a path, thank you.
[quote=496981:@Jean-Yves Pochez]then when you’re satisfied with it, modify the old project to use the new project architecture[/quote]Not sure what you mean here If I start from scratch, I’ll leave the old project behind, archived. The new version would be renamed.
[quote=496981:@Jean-Yves Pochez]with xojo refactoring tools , and external items, it’s a quite easy task.
but yes it takes time.[/quote]
I’ve had bad surprises with external items, mostly items becoming no longer external in the long run so my changes were no longer synced between projects. Then, once you discover that, you have to re-open all the projects, delete&reimport (as external anyway), check for compile errors and recompile (assuming you remember all the projects that need fixing); then you hope it won’t happen again, but it eventually does
But refactoring tools, I’m not sure what it means. I can refactor my projects from within the IDE alone; there are extra tools available? (I know about Arbed, but it didn’t worked in my case).
at job i worked at large projecs where the only option
was transform or replace things.
a new project is better for the developer but not
means that customers accept it.
i think its a matter of time(effort) & money.
if you have a product in shop and make a new one
the old project will not continue, not good for people that bought it.
Start by refactoring parts of the app into well-engineered replacements, one by one. Then if you decide to rewrite you can probably use those parts and save time. If you are lucky, the refactoring will eventually cover all the dodgy parts of the project and a rewrite wont be necessary.
Thank you for your advices.
My question was for when there are no customer or they don’t care about a rewrite, otherwise it’s clear one should fix the existing project (or rebuild the same one in parallel).
Refactoring is where I am at, somehow. Sometimes, I guess it would take too much time/resources to refactor some things, like a mainstay in the project.
As an example, I’m making a drawing app, mostly for my own use (or friends’). It started by only having vectorial items. Then, I eventually thought to add bitmap support. In the beginning, it was smooth. Then, I added support for various tools but I already got unthought issues for which I had to make workarounds. I managed to fix parts with unnecessary code, just because I didn’t wanted to rewrite all. Now, the app is drawing slowly and having hard-to-fix bugs.
The core logic of drawing should be thought again, flattening all the things I’ve stacked.
I now realise those are old projects and I didn’t take the good habits since the beginning
using external items and using them in multiple projects helps a lot to completely debug these methods.
if they work fine in multiple projects, you can consider them very good and use them in other projects as well.
I’m currently in the midst of exactly this situation with one of my own projects. I spent the lock-down learning more about object-oriented design and now, I’m looking at code that I wrote back in Jan, Feb, March and shaking my head. “What was I thinking?!”
I created a ‘Test’ project and rewrote the foundational stuff again. I implemented a couple of things just to test and refined them until they worked. I then created test implementations that would cover all of the scenarios that my main project might require and made sure that I had a solution for each one.
Now, I’m in the process of ‘fixing’ my old project. Replacing code and entire objects, as required on a window by window basis.
I find that keeping the old code in place and then switching things a little at a time works well. For example, if I had subclassed ListBox into mySpecialListBox, I would change the Super of any ListBoxes in my windows one at a time to myAwesomeListBox and test each one as I go.
The Analyze tool works wonders for this as long as your old code passed and you don’t destroy it but simply switch classes from old to new.
wrote as a to do document what the application have to do.
Then, I wrote what the design is (a Module with these Properties / Methods / Functions, Classes, etc.
Then, before starting a brand new project, I load what will be the old project and print it as PDF (with Windows).
Close / Quit all, shutdown, have a drink, be calm.
Then, with an afternoon in front of me, I Power on the computer, fire Xojo and create the new project (load the old project as pdf to copy the whole already written code, modifying it if needed).
I learned when I swapped from another software to REALbasic 1 (alpha 24 I think), it takes far less time to build an application when you already have the structure / images / in short: the design. I do not even used the old code (I wrote brand new code, RB code).
Some years ago, I erased a hard disk by error and really lost stuff; fortunately, I created a pdf of the whole project (for testing purposes) two days before. I rebuilt the project from a years old previous versionusing what I found in the PDF.
THe process takes some times, but it will gives you a version 2.0 (vs 1.0) and may allow you to really remove bugs and get far better code.
For commercial purposes, it may be done for a brand new version (refactoring) when the client want a newer version with additional features.
Don’t start the project over. Refactoring may take a lot of time, but starting over will always take significantly more. Your code is not 100% bad, but you’ll need to redo 100% of the work. Every project experiences these kinds of growing pains. The best planning won’t prevent that. The “you don’t know what you don’t know” factor will always be present, you just whittled it down over time. Take what you’ve learned and refactor what doesn’t work. Replace parts one-by-one, even if they’re big parts.
Thank you for these answers.
I’m seeing far more better to refactor answers, but there’s also some take the opportunity to start over ones. I guess there’s no strictly-absolute answer, albeit I agree with the code is not 100% bad but 100% of the work has to be redone fact (and almost everything said here).
For this specific project, I’ll take a mid-approach, since I started the project in 2008 and a lot of new set of controls/methods have appeared since then. I’ll redo the UI and import the classes from the old projects, making required adjustments for each class.
[quote=497170:@Jim Shaffer]Even if your software isn’t on a scale such as these some of this advice might be sound.
Joel on Software[/quote]
While at CERN, I once spoke to the guy responsible for mainaining WYLBUR, Stanford’s online text editor system for the IBM 370/168, which CERN had started using. He said there was a constant low-level of bugs, because the system had long since been expanded beyond its original design parameters. As a result, each time he fixed one bug, chances were another popped up somewhere else.
Of course, that was 40 and more years ago, and software design has improved since then. Perhaps it’s less of a problem since software is more modular now.