3 ms·

Rewriting is incredibly cheap! And you learn a lot from the failed attempts. Again to the house analogy, if you could just build 3 vestibules to see how they

by skohan 5y ago

Rewriting is incredibly cheap! And you learn a lot from the failed attempts. Again to the house analogy, if you could just build 3 vestibules to see how they fit with just a little typing, that would be far and away preferable to committing to everything on paper before hand.

gefhfffh 5y ago
No, it is not cheap, generally. Example: Dendrite[0] was going to be a Rewrite of Synapse (which was a prototype which ended up going into production). The rewrite started more than 5 years ago, had lots of development breaks and it still is nowhere complete or close to replace a existing Synapse instance (which even today is ... Well ... suboptimal software). The current plans are to support and use both servers long term, because Synapse is already too widespread. I wouldn't call that cheap. [0]: https://github.com/matrix-org/dendrite https://github.com/matrix-org/dendrite
- skohan 5y ago
  Well starting from scratch for a rewrite is generally a bad idea. I'm more a fan of incremental re-wrties. But I have code bases I have been working on for years with tens of thousands of lines where basically the entire thing gets rewritten ever 18 months or so, a bit at a time. Isn't your example proof of the benefit of pragmatic coding? Synapse is actually serving users right now. Dendrite sounds like a "better design" which is stuck in purgatory.
  - gefhfffh 5y ago
    They tried an incremental rewrite before. They failed, and started Dendrite. https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta
- MrPatan 5y ago
  Survivor bias. You don't see all the perfectly designed codebases that never went anywhere. We only talk about legacy code because it's the one that pays the bills.
vault_ 5y ago
That really depends on what you're working on and to what degree it's coupled to the system it's a part of. A form on a web application, or an API endpoint? Sure, rewriting it is probably trivial. A new process scheduler for Linux? The caching system in an HTTP server? Maybe writing the code will be easy (though probably not), but building any confidence that it doesn't break something that's unexpectedly load bearing will be anything but cheap. And if what you're rewriting that started out as "just code and see what happens" it's going to be more expensive still. Which isn't to say that rewriting can't be cheap, but some intentional design (or at least diligent maintenance and refactoring) must have gone into the system to support that style of development. At which point you're back to targeting "quality," even if it's no longer a focus of on the smaller scale.
nfw2 5y ago
Are you the only working on the codebase? It may be easy to rewrite your own codebase, but it's certainly not easy to rewrite someone else's. Especially if they haven't been caring about code quality and/or test coverage. My definition of "good-quality" code is pretty much exactly "how difficult would this codebase be for a new engineer to understand and modify safely."
- hinkley 5y ago
  You can go really really fast when you don’t give a shit about consequences. Often the worst code comes from prolific people. There’s just so much if it. And if you touch it you will break it at least 1% of the time, so you have to pick your battles when you are trying to keep the ratio under control.
  - skohan 5y ago
    If you write loosely-coupled code, it shouldn't be that easy to break things unless you're careless.
    - hinkley 5y ago
      If it were loosely coupled it wouldn’t be an anecdote in this conversation. There is no “I”, there is no “you”. There is only “us”. I can only control Us so much, and I don’t have a time machine. People who only have green field projects as their context are very frustrating in conversations like this. They make suggestions like, well, don’t fuck up in the first place. I don’t know what your history is but that’s the feeling I’m getting.
      - skohan 5y ago
        Not that it matters but I've worked on a mix of green-field projects and mature codebases in various domains with teams of various sizes over more than a decade of professional experience. I could assume you're throwing shade on "prolific programmers" out of some sense of insecurity, but it wouldn't be fair to generalize about strangers on the internet ;)
DerArzt 5y ago
How are defining cheep, and how big is the metaphorical house? Developer time is not free (unless you are working a personal project) and if an hour or two up front of planning things out stops you from making a lynch pin mistake that needs to be re-written it is better to do the planning. If the amount of time that it takes to rewrite something is trivial (a week or less) then you aren't working on something all that big/complicated.

by skohan 5y ago

gefhfffh 5y ago

No, it is not cheap, generally. Example: Dendrite[0] was going to be a Rewrite of Synapse (which was a prototype which ended up going into production). The rewrite started more than 5 years ago, had lots of development breaks and it still is nowhere complete or close to replace a existing Synapse instance (which even today is ... Well ... suboptimal software). The current plans are to support and use both servers long term, because Synapse is already too widespread. I wouldn't call that cheap. [0]: https://github.com/matrix-org/dendrite https://github.com/matrix-org/dendrite

skohan 5y ago
Well starting from scratch for a rewrite is generally a bad idea. I'm more a fan of incremental re-wrties. But I have code bases I have been working on for years with tens of thousands of lines where basically the entire thing gets rewritten ever 18 months or so, a bit at a time. Isn't your example proof of the benefit of pragmatic coding? Synapse is actually serving users right now. Dendrite sounds like a "better design" which is stuck in purgatory.
- gefhfffh 5y ago
  They tried an incremental rewrite before. They failed, and started Dendrite. https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta https://matrix.org/blog/2020/10/08/dendrite-is-entering-beta
MrPatan 5y ago
Survivor bias. You don't see all the perfectly designed codebases that never went anywhere. We only talk about legacy code because it's the one that pays the bills.

vault_ 5y ago

That really depends on what you're working on and to what degree it's coupled to the system it's a part of. A form on a web application, or an API endpoint? Sure, rewriting it is probably trivial. A new process scheduler for Linux? The caching system in an HTTP server? Maybe writing the code will be easy (though probably not), but building any confidence that it doesn't break something that's unexpectedly load bearing will be anything but cheap. And if what you're rewriting that started out as "just code and see what happens" it's going to be more expensive still. Which isn't to say that rewriting can't be cheap, but some intentional design (or at least diligent maintenance and refactoring) must have gone into the system to support that style of development. At which point you're back to targeting "quality," even if it's no longer a focus of on the smaller scale.

nfw2 5y ago

Are you the only working on the codebase? It may be easy to rewrite your own codebase, but it's certainly not easy to rewrite someone else's. Especially if they haven't been caring about code quality and/or test coverage. My definition of "good-quality" code is pretty much exactly "how difficult would this codebase be for a new engineer to understand and modify safely."

hinkley 5y ago
You can go really really fast when you don’t give a shit about consequences. Often the worst code comes from prolific people. There’s just so much if it. And if you touch it you will break it at least 1% of the time, so you have to pick your battles when you are trying to keep the ratio under control.
- skohan 5y ago
  If you write loosely-coupled code, it shouldn't be that easy to break things unless you're careless.
  - hinkley 5y ago
    If it were loosely coupled it wouldn’t be an anecdote in this conversation. There is no “I”, there is no “you”. There is only “us”. I can only control Us so much, and I don’t have a time machine. People who only have green field projects as their context are very frustrating in conversations like this. They make suggestions like, well, don’t fuck up in the first place. I don’t know what your history is but that’s the feeling I’m getting.
    - skohan 5y ago
      Not that it matters but I've worked on a mix of green-field projects and mature codebases in various domains with teams of various sizes over more than a decade of professional experience. I could assume you're throwing shade on "prolific programmers" out of some sense of insecurity, but it wouldn't be fair to generalize about strangers on the internet ;)

DerArzt 5y ago

How are defining cheep, and how big is the metaphorical house? Developer time is not free (unless you are working a personal project) and if an hour or two up front of planning things out stops you from making a lynch pin mistake that needs to be re-written it is better to do the planning. If the amount of time that it takes to rewrite something is trivial (a week or less) then you aren't working on something all that big/complicated.