Off-topic:
No developer knows what a new system's final code structure is going to look like before writing it. If you already pretty much know, then it's not a new system, and it's one you have basically written before. Only after the system works correctly and efficiently is the developer able to see what code structure would naturally fit the system, because the system didn't exist before it was written.
Like Tobin says, taking a codebase to the next level of functionality usually requires altering its structure, and changing a decent-sized structure is just *more work* than building it "right" from the ground up. When you already know exactly where you're going, it's much easier to get there. With no detours and trackbacks, it's faster too.
I call this development approach "building the architecture to be compatible with the functionality". Another significant benefit of this approach comes in the *next* round of development, where you can more-easily extend the second-round structure to accommodate additional functionality, because that extensibility was built in to the design from the start, and the structure already closely matches the functionality.
This level of code quality and architectural sophistication is impossible during the first round of development, because at that early stage you're just focused on getting the basics to operate without screwing up the data.
So a software's first draft is a hack that should be not used in production. The second draft is a mostly-usable stopgap. The third draft is finally good enough for other people to look at and depend on. Without this scale of iteration, projects tend to collapse under the unstable weight of their own rickety Goldberg-ian structure. If a package costs too much to upgrade, then it's a dead system. Any use it sees after that is just unholy consorting with a zombie. Writing non-contraptions is a basic requirement if you want any hope of ending up with a truly solid system.
This year I wrote a utility (twice) and then discovered I had also written practially the same thing (twice) in 2012. Each second round was a noticable improvment over the first round, and vastly more satisfying as a developer, because the code was correct for the task it performed, not just because the task got performed correctly and the output was useful. This utility is not just a tool. The source code is a work of art on its own, even if it never gets compiled. As its creator, it's not up to me to judge that artistry on its merits, but again as its creator, I am the only one with the need to feel artistically satisfied by the source code. If someone else ever appreciates that code by just reading it, then good on them, but that's an inconsequential side effect.
My rambling points out a constraint of commercial development that I would expect to be *free of* on projects such as this endeavor here. Yes, developers who actually care will make things take longer, but that's okay because their things end up *better*.
When writing actually-good non-trivial software, re-writing it two or three times is par for the course, and should be baked in to the roadmap. The only reason people don't know this, is commercial corporate development only needs to be "good enough" which actually means "pretty crappy".... why I am doing a rewrite of Phoebus from scratch instead of modifying the existing codebase. It is plain and simple: the changes needed to take it to the next level are so numerous that to continue down the path I started would literally be more work and the bulk of it would be changed or scrapped anyway.
No developer knows what a new system's final code structure is going to look like before writing it. If you already pretty much know, then it's not a new system, and it's one you have basically written before. Only after the system works correctly and efficiently is the developer able to see what code structure would naturally fit the system, because the system didn't exist before it was written.
Like Tobin says, taking a codebase to the next level of functionality usually requires altering its structure, and changing a decent-sized structure is just *more work* than building it "right" from the ground up. When you already know exactly where you're going, it's much easier to get there. With no detours and trackbacks, it's faster too.
I call this development approach "building the architecture to be compatible with the functionality". Another significant benefit of this approach comes in the *next* round of development, where you can more-easily extend the second-round structure to accommodate additional functionality, because that extensibility was built in to the design from the start, and the structure already closely matches the functionality.
This level of code quality and architectural sophistication is impossible during the first round of development, because at that early stage you're just focused on getting the basics to operate without screwing up the data.
So a software's first draft is a hack that should be not used in production. The second draft is a mostly-usable stopgap. The third draft is finally good enough for other people to look at and depend on. Without this scale of iteration, projects tend to collapse under the unstable weight of their own rickety Goldberg-ian structure. If a package costs too much to upgrade, then it's a dead system. Any use it sees after that is just unholy consorting with a zombie. Writing non-contraptions is a basic requirement if you want any hope of ending up with a truly solid system.
This year I wrote a utility (twice) and then discovered I had also written practially the same thing (twice) in 2012. Each second round was a noticable improvment over the first round, and vastly more satisfying as a developer, because the code was correct for the task it performed, not just because the task got performed correctly and the output was useful. This utility is not just a tool. The source code is a work of art on its own, even if it never gets compiled. As its creator, it's not up to me to judge that artistry on its merits, but again as its creator, I am the only one with the need to feel artistically satisfied by the source code. If someone else ever appreciates that code by just reading it, then good on them, but that's an inconsequential side effect.
My rambling points out a constraint of commercial development that I would expect to be *free of* on projects such as this endeavor here. Yes, developers who actually care will make things take longer, but that's okay because their things end up *better*.
