6 ms·

To be fair,everybody in web development knows the same thing is true for the internet.

joshstrange 7y ago
s/web/software/ s/internet/everything/ I can't tell you how many times I have to reteach myself this lesson. I'm not advocating for writing sloppy/bad code on purpose but I fall into the trap way too often of trying to make my code a work of art or overly-clever. No one cares, don't spend twice the time to try to abstract something within an inch of its life. Write working code and move on. Once you've done something 4, 5, 10, 15 times then you can look for an abstraction. Really I think I use refactoring or "stressing over the best way" really to just be a way to procrastinate and tell myself I'm doing something useful or dare I say noble. Of course in practice it's often neither.
- downerending 7y ago
  Agree, though I'd add s/many games/the world/g
- nmfisher 7y ago
  Agreed, I think it's important to bear in mind the "time value of code". Some code may very well be "set and forget" - you write it once and noone ever looks at it ever again. If a project is allocated 100 days, why invest even 1 of those refactoring and polishing code that really doesn't need it? The difficulty, of course is knowing which code is 'set and forget' and which isn't. I usually avoid refactoring until you hit the same "how does this work again?" wall at least three times.
- cjfd 7y ago
  Sounds more like too little care rather than too much. Of course it also depends on how much maintenance is going to occur on that code. I think in production code one should already look for an abstraction if something is done twice. The goal is not to create a work of art or an abstraction that stands the test of time. It is just to remove some duplication, distribute code a little better over functions, give things names that are somewhat better and so on. If one does a bit of that every day one is never going to be in a horrible mess. One problem is that people sometimes think that refactoring is all or nothing. You either refactor nothing or you go all the way to adhere exactly to design patterns. Neither of these two extremes produces very good code. The middle way is where the good code is.
  - pure-awesome 7y ago
    I used to think that if something is done twice, it should be abstracted. Now, I'm a bit more careful. There's a pretty famous quote by Sandi Mentz: "Duplication is far cheaper than the wrong abstraction." https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti... Make sure that you're picking the write way to think about the task at hand, rather than blindly following DRY. There are times when even a single instance of a code call would be made clearer with abstraction, and there are times where having the same piece of code duplicated multiple times (or duplicated with one piece changed) is far clearer than trying to abstract it. This Reddit Comment also has an interesting take: https://www.reddit.com/r/programming/comments/5txp5t/duplication_is_far_cheaper_than_the_wrong/ddq5ykf https://www.reddit.com/r/programming/comments/5txp5t/duplica... > The main purpose of abstractions is not to remove or reduce duplication, and not even to make code "reusable"; it is to make semantic patterns and assumptions explicit and, if possible, first-class. The further comments provide more discussion. --- I agree with the rest of your comment that refactoring and code-cleanup should be done in pieces and that, as with everything, striking the right balance is key.
    - cjfd 7y ago
      If there is any article that I absolutely hate it is 'Duplication is far cheaper than the wrong abstraction'. A somewhat minimal abstraction has very little chance of being wrong. And if it is wrong, is it really that difficult to know? It has a chance of needing some improvement, but what code does not have a chance of needing some improvement? If one goes the full monty and introduces three design patterns every time that two lines are duplicated sometimes one will certainly end up with, perhaps, not so much the wrong abstraction as an overly convoluted one. This acticle is the excuse for programmers everywhere not to fix their messes. It is 100% opposite to what programmers need to hear.
      - mcphage 7y ago
        > It is 100% opposite to what programmers need to hear. Maybe you know very different programmers than I have known, but if I had to compare what has been a bigger source of problems—missed abstractions, or abstractions that make things more difficult for no benefit, it's definitely bad abstractions almost every time.
- commandlinefan 7y ago
  > I'm not advocating for writing sloppy/bad code on purpose Well, if the “ugly” code works the same as the “pretty” code, but the ugly code can be developed faster than the pretty code, then you should definitely prefer the ugly code: in fact, if this is the case, the ugly code should be considered state-of-the-art because it can be written faster. Since we all accept that the pretty code takes longer, it had better pay for itself in some way. The theory is that the pretty code is easier to maintain over time: it takes longer up front, but when it comes time to make a change, since the code is so maintainable, the change is easier to make. Although that makes intuitive sense, I can’t say that that’s been my experience; in 30 years of software development, I’ve never come across code that’s particularly easier to make changes to than any other. I’ve tried to take maintainability into account when I’m writing code myself, and I can’t even think of a time when I had to make a change and found that my foresight saved me time and effort. It doesn’t help much that none of us agree on what “good quality” code looks like: everybody seems to call all code “bad”. I’ve I’d like to see software development advance a bit in terms of professionalism where we at least agree on the principles of high-quality software code, and the principles are objectively defensible in terms of what the cost/benefits of following them are.
Cthulhu_ 7y ago
And yet every time one starts a new project, we tell ourselves "this time I will do it better!" I just started a new big project. Wish me luck. It replaces something held together with duct tape and string concatenation in 5000 line files.
- croon 7y ago
  To be fair, you probably do a bit better this time around. Most likely not on most counts, but you probably internalized a few mistakes from last time and improved on those aspects. And come next project, you'll improve on a few more. You'll do great!
hyperpallium 7y ago
It has a light side, a dark side and it binds the whole universe together.
gempir 7y ago
Web Development is very different I feel. Web devs iterate on their product a lot more. A game is shipped. There is nothing after its shipped besides minor patches (if we ignore multiplayer online games) Web developers constantly need to fulfill new requirements so having a good level of code quality is important.
- timw4mail 7y ago
  You might think so, but it really depends on the culture and philosophy of the company. "Let's rewrite this old messy app in 'modern' technology" - sure it seems cleaner at first, but when you actually reach parity with the old app, you are likely about as messy. I tend to think that a lot of the messiness in business apps is more due to the complexity of the business rules than the structure of the application.
rb808 7y ago
That's not true, I know of several projects that were very well written with cutting edge frameworks, elegant abstractions, full test suites and balanced 40 hour weeks. Of course none of them ever went live lol.

s/web/software/ s/internet/everything/ I can't tell you how many times I have to reteach myself this lesson. I'm not advocating for writing sloppy/bad code on purpose but I fall into the trap way too often of trying to make my code a work of art or overly-clever. No one cares, don't spend twice the time to try to abstract something within an inch of its life. Write working code and move on. Once you've done something 4, 5, 10, 15 times then you can look for an abstraction. Really I think I use refactoring or "stressing over the best way" really to just be a way to procrastinate and tell myself I'm doing something useful or dare I say noble. Of course in practice it's often neither.

downerending 7y ago
Agree, though I'd add s/many games/the world/g
nmfisher 7y ago
Agreed, I think it's important to bear in mind the "time value of code". Some code may very well be "set and forget" - you write it once and noone ever looks at it ever again. If a project is allocated 100 days, why invest even 1 of those refactoring and polishing code that really doesn't need it? The difficulty, of course is knowing which code is 'set and forget' and which isn't. I usually avoid refactoring until you hit the same "how does this work again?" wall at least three times.
cjfd 7y ago
Sounds more like too little care rather than too much. Of course it also depends on how much maintenance is going to occur on that code. I think in production code one should already look for an abstraction if something is done twice. The goal is not to create a work of art or an abstraction that stands the test of time. It is just to remove some duplication, distribute code a little better over functions, give things names that are somewhat better and so on. If one does a bit of that every day one is never going to be in a horrible mess. One problem is that people sometimes think that refactoring is all or nothing. You either refactor nothing or you go all the way to adhere exactly to design patterns. Neither of these two extremes produces very good code. The middle way is where the good code is.
- pure-awesome 7y ago
  I used to think that if something is done twice, it should be abstracted. Now, I'm a bit more careful. There's a pretty famous quote by Sandi Mentz: "Duplication is far cheaper than the wrong abstraction." https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstraction https://www.sandimetz.com/blog/2016/1/20/the-wrong-abstracti... Make sure that you're picking the write way to think about the task at hand, rather than blindly following DRY. There are times when even a single instance of a code call would be made clearer with abstraction, and there are times where having the same piece of code duplicated multiple times (or duplicated with one piece changed) is far clearer than trying to abstract it. This Reddit Comment also has an interesting take: https://www.reddit.com/r/programming/comments/5txp5t/duplication_is_far_cheaper_than_the_wrong/ddq5ykf https://www.reddit.com/r/programming/comments/5txp5t/duplica... > The main purpose of abstractions is not to remove or reduce duplication, and not even to make code "reusable"; it is to make semantic patterns and assumptions explicit and, if possible, first-class. The further comments provide more discussion. --- I agree with the rest of your comment that refactoring and code-cleanup should be done in pieces and that, as with everything, striking the right balance is key.
  - cjfd 7y ago
    If there is any article that I absolutely hate it is 'Duplication is far cheaper than the wrong abstraction'. A somewhat minimal abstraction has very little chance of being wrong. And if it is wrong, is it really that difficult to know? It has a chance of needing some improvement, but what code does not have a chance of needing some improvement? If one goes the full monty and introduces three design patterns every time that two lines are duplicated sometimes one will certainly end up with, perhaps, not so much the wrong abstraction as an overly convoluted one. This acticle is the excuse for programmers everywhere not to fix their messes. It is 100% opposite to what programmers need to hear.
    - mcphage 7y ago
      > It is 100% opposite to what programmers need to hear. Maybe you know very different programmers than I have known, but if I had to compare what has been a bigger source of problems—missed abstractions, or abstractions that make things more difficult for no benefit, it's definitely bad abstractions almost every time.
commandlinefan 7y ago
> I'm not advocating for writing sloppy/bad code on purpose Well, if the “ugly” code works the same as the “pretty” code, but the ugly code can be developed faster than the pretty code, then you should definitely prefer the ugly code: in fact, if this is the case, the ugly code should be considered state-of-the-art because it can be written faster. Since we all accept that the pretty code takes longer, it had better pay for itself in some way. The theory is that the pretty code is easier to maintain over time: it takes longer up front, but when it comes time to make a change, since the code is so maintainable, the change is easier to make. Although that makes intuitive sense, I can’t say that that’s been my experience; in 30 years of software development, I’ve never come across code that’s particularly easier to make changes to than any other. I’ve tried to take maintainability into account when I’m writing code myself, and I can’t even think of a time when I had to make a change and found that my foresight saved me time and effort. It doesn’t help much that none of us agree on what “good quality” code looks like: everybody seems to call all code “bad”. I’ve I’d like to see software development advance a bit in terms of professionalism where we at least agree on the principles of high-quality software code, and the principles are objectively defensible in terms of what the cost/benefits of following them are.

Cthulhu_ 7y ago

And yet every time one starts a new project, we tell ourselves "this time I will do it better!" I just started a new big project. Wish me luck. It replaces something held together with duct tape and string concatenation in 5000 line files.

croon 7y ago
To be fair, you probably do a bit better this time around. Most likely not on most counts, but you probably internalized a few mistakes from last time and improved on those aspects. And come next project, you'll improve on a few more. You'll do great!

hyperpallium 7y ago

It has a light side, a dark side and it binds the whole universe together.

gempir 7y ago

Web Development is very different I feel. Web devs iterate on their product a lot more. A game is shipped. There is nothing after its shipped besides minor patches (if we ignore multiplayer online games) Web developers constantly need to fulfill new requirements so having a good level of code quality is important.

timw4mail 7y ago
You might think so, but it really depends on the culture and philosophy of the company. "Let's rewrite this old messy app in 'modern' technology" - sure it seems cleaner at first, but when you actually reach parity with the old app, you are likely about as messy. I tend to think that a lot of the messiness in business apps is more due to the complexity of the business rules than the structure of the application.

rb808 7y ago

That's not true, I know of several projects that were very well written with cutting edge frameworks, elegant abstractions, full test suites and balanced 40 hour weeks. Of course none of them ever went live lol.