6 ms·

It's both. Some of my worst code was to look at someone else's code after a manager shouted "FIX THIS NOW!!!" with some kind of quick and dirty hack, and then n

It's both. Some of my worst code was to look at someone else's code after a manager shouted "FIX THIS NOW!!!" with some kind of quick and dirty hack, and then never going back to get it done right. I'm pretty sure this happens independent of whether or not I am any good. :-)

mtbcoder 11y ago
Happens to the best of us! Also, it's very difficult to keep entropy at bay in something that requires so much abstract thought and effort as programming, especially with how broad software's reach has gotten.
ktRolster 11y ago
When you're really good, you learn to FIX IT NOW while also not making a hack. Your code becomes flexible enough to handle that kind of change.
- st3v3r 11y ago
  That's assuming it's your code. Most of the time it's not your code. While one would hope that the rest of the team writes flexible code as well, that's not always the case.
  - ktRolster 11y ago
    Then settle for making the code better than it was when you started working on it.
- szatkus 11y ago
  Usually it's not my code :/
- chimprich 11y ago
  You can't anticipate every emergency change required to the codebase. Sure, you can make some intelligent predictions about certain points in the code and encapsulate possible changes but it's impossible in the general case. Trying to code to future possible requirements is often far more harmful because of over-abstraction than occasionally having to perform a quick hack and then fix it later.
  - ktRolster 11y ago
    Yeah. It's a balance between "build as little 'framework code' as possible;" and "build the framework as you go." I say 'framework code' but it could be called structural code, or glue code or something, too.
- mathattack 11y ago
  I'm not that good to pull that off with other people's code. :-)
  - ktRolster 11y ago
    Nah, you're good enough. If the code is bad, change your goal to "make it better than it was when I got here." That's something you can do.
collyw 11y ago
I was having this dilemma on my walk home. I try to write good idiomatic Django code, and know how to make it efficient in the ways described in Two Scoops (a book about Django best practices). I have inherited an app, parts of which are exactly the opposite of Django best practices (thin models fat controllers being the most obvious one - the application's documentation says that's the philosophy , while Django encourages, and works better the opposite way). So do I spend more time refactoring and bringing this application to a decent state, or do I just keep on hacking more crap on to it? No one except for me seems to give a shit as long as it seems to be working.
- JoeAltmaier 11y ago
  A rewrite is a different animal than writing new code. The problem with rewrites is the marginal utility is a diminishing return. Unless the code is really bad, or will require very frequent revisits.
- mathattack 11y ago
  I think the best practice is to just refactor the bits that you need to touch. At a minimum avoid leaving them worse, and in an ideal world leave each piece you touch better for your having looked at it.
  - collyw 11y ago
    Thats my plan, assuming i get the chance to.

mtbcoder 11y ago

Happens to the best of us! Also, it's very difficult to keep entropy at bay in something that requires so much abstract thought and effort as programming, especially with how broad software's reach has gotten.

ktRolster 11y ago

When you're really good, you learn to FIX IT NOW while also not making a hack. Your code becomes flexible enough to handle that kind of change.

st3v3r 11y ago
That's assuming it's your code. Most of the time it's not your code. While one would hope that the rest of the team writes flexible code as well, that's not always the case.
- ktRolster 11y ago
  Then settle for making the code better than it was when you started working on it.
szatkus 11y ago
Usually it's not my code :/
chimprich 11y ago
You can't anticipate every emergency change required to the codebase. Sure, you can make some intelligent predictions about certain points in the code and encapsulate possible changes but it's impossible in the general case. Trying to code to future possible requirements is often far more harmful because of over-abstraction than occasionally having to perform a quick hack and then fix it later.
- ktRolster 11y ago
  Yeah. It's a balance between "build as little 'framework code' as possible;" and "build the framework as you go." I say 'framework code' but it could be called structural code, or glue code or something, too.
mathattack 11y ago
I'm not that good to pull that off with other people's code. :-)
- ktRolster 11y ago
  Nah, you're good enough. If the code is bad, change your goal to "make it better than it was when I got here." That's something you can do.

collyw 11y ago

I was having this dilemma on my walk home. I try to write good idiomatic Django code, and know how to make it efficient in the ways described in Two Scoops (a book about Django best practices). I have inherited an app, parts of which are exactly the opposite of Django best practices (thin models fat controllers being the most obvious one - the application's documentation says that's the philosophy , while Django encourages, and works better the opposite way). So do I spend more time refactoring and bringing this application to a decent state, or do I just keep on hacking more crap on to it? No one except for me seems to give a shit as long as it seems to be working.

JoeAltmaier 11y ago
A rewrite is a different animal than writing new code. The problem with rewrites is the marginal utility is a diminishing return. Unless the code is really bad, or will require very frequent revisits.
mathattack 11y ago
I think the best practice is to just refactor the bits that you need to touch. At a minimum avoid leaving them worse, and in an ideal world leave each piece you touch better for your having looked at it.
- collyw 11y ago
  Thats my plan, assuming i get the chance to.