Restarting Projects
So I've been working on my little GUI library quite a bit, everything was working great- up until I tried to make a realtime window a child of a non-realtime window.
The problem was quite mysterious, and I spent several days trying to resolve it- got too frustrated with staring at the same code and decided to redo the project.
What a splendid result! Not only did I resolve the realtime issue but I added quite a few additional features and made the whole structure way more robust! Normally I shy away from completely restarting a project but wow the results from this one overhaul may have just converted me to Kent Beck's Paradigm
What do you all think about starting a large (solo) project over on occasion? Healthy or unhealthy?
The problem was quite mysterious, and I spent several days trying to resolve it- got too frustrated with staring at the same code and decided to redo the project.
What a splendid result! Not only did I resolve the realtime issue but I added quite a few additional features and made the whole structure way more robust! Normally I shy away from completely restarting a project but wow the results from this one overhaul may have just converted me to Kent Beck's Paradigm
| first make it work, then make it right, and, finally, make it fast. |
What do you all think about starting a large (solo) project over on occasion? Healthy or unhealthy?
When you first make something new, you are poking around in the dark and don't really know what obstacles or traps you will run into. When you start over, it's still the exact same room, but this time you know some of the obstacles and traps in advance and can plan for them. The trick is knowing when and why to start over, and to avoid becoming a phoenix.
Last edited on
It's healthy to an extent.
There are two main trains of thought here, represented by software management paradigms:
Waterfall: "Change is expensive. Minimize it". The idea here is that you want to define your requirements ahead of time, create a design, and only after you've figured everything out, implement it. It's a very conventional way of software development.
Agile: "Change is inevitable. Utilize it". The idea here is that you want to create something, figure out if it is what you're looking for at regular intervals, then make changes so that the customer ends up with something that they actually wanted. It's about encouraging constant "refactoring".
There are two main trains of thought here, represented by software management paradigms:
Waterfall: "Change is expensive. Minimize it". The idea here is that you want to define your requirements ahead of time, create a design, and only after you've figured everything out, implement it. It's a very conventional way of software development.
Agile: "Change is inevitable. Utilize it". The idea here is that you want to create something, figure out if it is what you're looking for at regular intervals, then make changes so that the customer ends up with something that they actually wanted. It's about encouraging constant "refactoring".
It just requires some judgement. Are you creating a new, more robust design that will be make the code easier to write and maintain, or throwing out the baby with the bath water?
A friend of mine says that you have to write software 3 times to get it right. The first time lets you truly understand all the requirements. The other 2 are getting the design right.
On big systems, it's important to note that the requirements change over time. Where I work, we did a complete redesign and rewrite of the heart of the system in 1996. It went online in 2000 and it's been going strong with constant updates and new features ever since.
Another time we needed a database to handle some tough performance requirements for rapidly growing data and we needed it fast. The "right" solution was going to take a too long to develop so we created a throw-away solution that would handle the data for a few months while we created the "right" solution.
A friend of mine says that you have to write software 3 times to get it right. The first time lets you truly understand all the requirements. The other 2 are getting the design right.
On big systems, it's important to note that the requirements change over time. Where I work, we did a complete redesign and rewrite of the heart of the system in 1996. It went online in 2000 and it's been going strong with constant updates and new features ever since.
Another time we needed a database to handle some tough performance requirements for rapidly growing data and we needed it fast. The "right" solution was going to take a too long to develop so we created a throw-away solution that would handle the data for a few months while we created the "right" solution.
I've always felt that the trick is to stick to a modular design so that the refactoring that does take place is only on a little bit at a time. This way when something breaks due to your changes, and it will from time to time, there is no question about what broke and where.
The most important thing to remember though is that disk space is cheap, and text compresses very well. So there is no need to ever delete your old code; just zip it up and stash it somewhere out of sight. That and labeling, labeling is also important. I can't even count how many times I've been screwing around with some new thing in a folder called "Test" only to delete it the next week because I forgot what it was and didn't think that a folder with a name like "Test" held anything important. I am my own worst enemy.
The most important thing to remember though is that disk space is cheap, and text compresses very well. So there is no need to ever delete your old code; just zip it up and stash it somewhere out of sight. That and labeling, labeling is also important. I can't even count how many times I've been screwing around with some new thing in a folder called "Test" only to delete it the next week because I forgot what it was and didn't think that a folder with a name like "Test" held anything important. I am my own worst enemy.
| Computergeek01 wrote: |
|---|
| The most important thing to remember though is that disk space is cheap, and text compresses very well. So there is no need to ever delete your old code; just zip it up and stash it somewhere out of sight. |
| first make it work, then make it right, and, finally, make it fast. |
I think that's just a general rule of software engineering... All any company (with the obvious exceptions) cares about is the end result, not necessarily the underlying implementation.
And, quite frankly, it's nice when, as a programmer, you can see the results of your work without spending days on making it "right" or "fast".
My personal preference these days has been towards not restarting projects unless necessary, and to abide by that rule of thumb from the start. It seems to have worked well enough so far.
Last edited on
Computer programming is a light-hearted endeavor unless you have a horde of zembies trying to eat ya' face (a solo game project of mine): https://store7697404.ecwid.com/#!/SIMCUBE%E2%84%A2-PC-video-game/p/58053312/category=0
Topic archived. No new replies allowed.