"Space is big. You just won't believe how vastly, hugely, mind- bogglingly big it is. I mean, you may think it's a long way down the road to the drug store, but that's just peanuts to space."
- Douglas Adams
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 96 97 98 99 100 101 102 103 104 105 106 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 371 ... 381 ... 391 ... 401 ... 411 ... 421 ... 431 ... 438
Query FailedAxel
Friday, December 2, 2011

Winamp also did a rewrite with Winamp 3 that failed (bloated, slow, etc.). They backported most of the stuff to the Winamp 2 code base and called it Winamp 5 (2 + 3 equals 5, right?)

So copy framework 3, backport the changes from 4 and call it framework 7
Overlord
Friday, December 2, 2011

In my experience rewriting parts of the code on a continuing basis and having a plan for doing so is the key to having all your stuff up to date.
I probably spend more time planing what and how to code than i do actual coding.
I also tend to write code for just this purpose from the beginning by having things being pretty much self contained so i can just swap out a piece whenever i like.

Total rewrites are never a good idea, though every so often i still find myself wanting to do it, either way i am pretty soon forced to do it anyway as my last/first engine is pretty old and no amount of re jiggering can fix that mess.
I just hope it doesn't take that long (though it probably will).
@jlauha
Friday, December 2, 2011

Copy the Framework3 to Framework5 and fix the most important things.

Wouldn't be the first time in history when "version 4" never gets out (at least Microsoft doesn't seem to like v4, e.g. DirectX 4 was never released).
Nick
Friday, December 2, 2011

Since I don't know your whole situation and experiences, you can take this comment or leave it, I'm commenting from my own perspective on similar efforts -

I wouldn't consider the rewrite wasted effort at all. It sounds to me like you learned plenty, including what was good about your previous framework. If you don't try something like that, you'll never know. Going through the experience you did also means that next time you find yourself in a situation you'll be better able to know when to cut your losses.

I sometimes embark on a rewrite knowing that I will throw it away. Sometimes I do it because I have an idea that I want to try out, or sometimes I want to prove to myself that some great idea is not really that great - and a lot of the time the only way to know know those things is to do it.
Ashkan (@Aphrodite3D)
Friday, December 2, 2011

Don't rewrite a software and you have to deal with the same mess each day, every day, watching it getting worse and worse by the day, until production literally grinds to a halt. In such a code base, there would eventually come a time that we, as software developers, would be ever-increasingly spending more and more time hacking around to fix a bug or get the new feature/improvement play *nicely* with the rest of the codebase. When your code is a mess, debugging suffers, readability suffers, productivity suffers, scalability suffers, performance suffers, hell even the business itself suffers as it slowly starts to loose its competitive edge since adding new features or fixing newly found bugs (not to mention that messy code is prone to producing more bugs in the first place) takes more and more resources, be it time or money. You are loosing an all grounds. Period. Moral of the story: Not re-writing software sucks. Rewriting software also sucks. We either have to choose between the lesser of two evil when it's too late, or be smart from the get go and write overall clean software and strive to keep it in good shape. That's the lesson that software developers and business owners must learn. That's the lesson that must be tune to their ears. A lesson, which as a result of short-sightedness, they seem to be so fervently resist to acknowledge. Hacks will always come back to bite us in the ass. That's the golden rule. Rewriting is evil, sure, but it's not the root of all evil. Hacking is the root of all evil. Hacking is the reason why re-writes eventually become so devilishly tempting, and as long as we so ceaselessly insist on making the same mistake over and over again we're doomed to live the same fucking hell over and over again.

Hoof! Had to take this off my chest!

- Peace
Ashkan (@Aphrodite3D)
Friday, December 2, 2011

Don't rewrite a software and you have to deal with the same mess each day, every day, watching it getting worse and worse by the day, until production literally grinds to a halt. In such a code base, there would eventually come a time that we, as software developers, would be ever-increasingly spending more and more time hacking around to fix a bug or get the new feature/improvement play *nicely* with the rest of the codebase. When your code is a mess, debugging suffers, readability suffers, productivity suffers, scalability suffers, performance suffers, hell even the business itself suffers as it slowly starts to loose its competitive edge since adding new features or fixing newly found bugs (not to mention that messy code is prone to producing more bugs in the first place) takes more and more resources, be it time or money. You are loosing an all grounds. Period. Moral of the story: Not re-writing software sucks. Rewriting software also sucks. We either have to choose between the lesser of two evil when it's too late, or be smart from the get go and write overall clean software and strive to keep it in good shape. That's the lesson that software developers and business owners must learn. That's the lesson that must be tune to their ears. A lesson, which as a result of short-sightedness, they seem to be so fervently resist to acknowledge. Hacks will always come back to bite us in the ass. That's the golden rule. Rewriting is evil, sure, but it's not the root of all evil. Hacking is the root of all evil. Hacking is the reason why re-writes eventually become so devilishly tempting, and as long as we so ceaselessly insist on making the same mistake over and over again we're doomed to live the same fucking hell over and over again.

Hoof! Had to take this off my chest!

- Peace
xoofx
Friday, December 2, 2011

Indeed!

Though, as your story implies, there is a noticeable difference between rewrite a whole application from scratch then rewrite part of the code from scratch.
If the original application is using components/interfaces layers between parts of the code, It is always easier to plugin-in a new underlying implem, sometimes by tweaking the interface to reflect the new features into other parts of the application, with a manageable impact, without having to break the whole code, as you probably did for your Framework3.
The question of rewrite from scratch arise when the paradigm of the whole design of the application is completely changing: meaning that external interfaces are changing as well as the whole internal plumbing, interfaces, workflows, datas... etc. In the end, this is not a rewrite but a new engineering of a solution.
In the case of AMD OpenGL story, as the external interface was obviously not changing, the rewrite of such a critical component was clearly not a good move. It would have been more careful to identify key part of the component to rewrite, and start incrementally from here.
Humus
Friday, November 18, 2011

Nah, fortunately posts like that are quicker to delete than for someone to type up.
More pages: 1 ... 11 ... 21 ... 31 ... 41 ... 51 ... 61 ... 71 ... 81 ... 91 ... 96 97 98 99 100 101 102 103 104 105 106 ... 111 ... 121 ... 131 ... 141 ... 151 ... 161 ... 171 ... 181 ... 191 ... 201 ... 211 ... 221 ... 231 ... 241 ... 251 ... 261 ... 271 ... 281 ... 291 ... 301 ... 311 ... 321 ... 331 ... 341 ... 351 ... 361 ... 371 ... 381 ... 391 ... 401 ... 411 ... 421 ... 431 ... 438