3 ms·

Probably not literally without cost, but if the code was written with disposability in mind combined with just a little bit of pre-planning, then rewriting or r

by runald 5y ago

Probably not literally without cost, but if the code was written with disposability in mind combined with just a little bit of pre-planning, then rewriting or refactoring should be indeed trivial.

gefhfffh 5y ago
When start off with "wrong" higher level design concepts, neither of those is trivial. If you're writing a function implementation without thinking about design, well you might be right.
- sseagull 5y ago
  I sometimes wonder if there is a miscommunication. I’m scratching my head sometimes like “how can rewriting/refactoring an entire 10-20k project take negligible time?” Maybe some people have very small projects compared to what I work on? Or maybe they are talking about the design of a single small component? I inherited a codebase that needed some refactoring because it was written “to just get it shipped”. If completely fell apart with more users and has taken me a year to get it where it needs to be.
  - deleted 5y ago
    [deleted]
  - skohan 5y ago
    But how often would you actually have to rewrite an entire 10-20k LOC project at once? As you need to add functionality, you can opportunistically find ways to improve the codebase toward a better/more maintainable structure. I have several large codebases I work on which probably get totally rewritten every 18 months or 2 years, however incrementally. If you have a working project and you think you need to throw it all out and start from scratch probably it's worth a second thought.
  - hinkley 5y ago
    We always talk about time when the elephant in the room is energy. People say we don’t have “time” for that and someone else gets out a calendar and tries to disprove them. Followed by a bunch of backpedaling with other excuses and followed up with foot dragging. The second elephant in the room is job security. People who write baroque code are hard to fire. Nobody wants to invest energy in understanding their private little Bedlam.
- runald 5y ago
  When starting, yes it's easy to replace code, even with a shitty design. If it had to take more than ten hundred thousands lines of code to realize that the design is wrong, then it means the author lacks enough awareness or foresight to plan ahead, and no amount of planning will fix that. Code should be replaced/rewritten if the earliest signs faulty design show up, which should be trivial if the code was and remains "disposable".
mint2 5y ago
Not having to pay for physical materials doesn’t mean there are no costs. Throwing hours, days, or weeks of focused work time out the window does not sound cost free to me or Whoever signs paychecks.
- skohan 5y ago
  It's not throwing it out the window if it's an iteration toward a better solution. There's a reason nobody does waterfall anymore in software - up-front planning is less productive than rapid prototyping in most cases.

by runald 5y ago

Probably not literally without cost, but if the code was written with disposability in mind combined with just a little bit of pre-planning, then rewriting or refactoring should be indeed trivial.

gefhfffh 5y ago

When start off with "wrong" higher level design concepts, neither of those is trivial. If you're writing a function implementation without thinking about design, well you might be right.

sseagull 5y ago
I sometimes wonder if there is a miscommunication. I’m scratching my head sometimes like “how can rewriting/refactoring an entire 10-20k project take negligible time?” Maybe some people have very small projects compared to what I work on? Or maybe they are talking about the design of a single small component? I inherited a codebase that needed some refactoring because it was written “to just get it shipped”. If completely fell apart with more users and has taken me a year to get it where it needs to be.
- deleted 5y ago
  [deleted]
- skohan 5y ago
  But how often would you actually have to rewrite an entire 10-20k LOC project at once? As you need to add functionality, you can opportunistically find ways to improve the codebase toward a better/more maintainable structure. I have several large codebases I work on which probably get totally rewritten every 18 months or 2 years, however incrementally. If you have a working project and you think you need to throw it all out and start from scratch probably it's worth a second thought.
- hinkley 5y ago
  We always talk about time when the elephant in the room is energy. People say we don’t have “time” for that and someone else gets out a calendar and tries to disprove them. Followed by a bunch of backpedaling with other excuses and followed up with foot dragging. The second elephant in the room is job security. People who write baroque code are hard to fire. Nobody wants to invest energy in understanding their private little Bedlam.
runald 5y ago
When starting, yes it's easy to replace code, even with a shitty design. If it had to take more than ten hundred thousands lines of code to realize that the design is wrong, then it means the author lacks enough awareness or foresight to plan ahead, and no amount of planning will fix that. Code should be replaced/rewritten if the earliest signs faulty design show up, which should be trivial if the code was and remains "disposable".

mint2 5y ago

Not having to pay for physical materials doesn’t mean there are no costs. Throwing hours, days, or weeks of focused work time out the window does not sound cost free to me or Whoever signs paychecks.

skohan 5y ago
It's not throwing it out the window if it's an iteration toward a better solution. There's a reason nobody does waterfall anymore in software - up-front planning is less productive than rapid prototyping in most cases.