3 ms·

Any day that has a negative LOC count is a good day :) This usually means I found a good refactoring, or a good abstraction that removes a lot of stuff that is

Any day that has a negative LOC count is a good day :) This usually means I found a good refactoring, or a good abstraction that removes a lot of stuff that is now boilerplate. If I can also add a feature with a negative net LOC count, it is a gold-star day :) That being said, sometimes just dumping a pile of code that passes tests, but is large (bloated), unwieldy and redundant is the right move. It give me something to refactor and abstract, and gets things done. It's all about balance.

evincarofautumn 14y ago
I’m with you. The most rewarding thing about diving into a large codebase is that you have many opportunities to refactor while you add features. At my current job I add only marginally more code than I delete. Feels good. :)
- getspeedly 14y ago
  Sure -- as long as there are tests and some semblance of order. Trying to add new features to an untested ball of mud is just about the worst possible thing one can inflict on a poor programmer.
  - evincarofautumn 14y ago
    Yeah, luckily, the guy I’m working with is quite good about testing. If that weren’t the case, then I’d have a different opinion…
chipsy 14y ago
I consider the big-ugly code to be a part of the learning curve - it exposes "concrete" problems of implementation, and once built, you nurse it through a few rounds of changes before a major refactor or redesign to sweep up all the new concerns. The main problem of this strategy is with other people - as soon as you have a whole team pounding away at the same piece of code, the incremental changes obscure a high-level revised view of the problem, being distributed across several minds. Descent into a ball of mud becomes the status quo. On the other hand, optimizing the source text prematurely(either via code golf or Big Architecture) is even worse since it's not even built on a stable foundation of intention, then, but on guesses or convenient hacks.
caseysoftware 14y ago
Deleted code is the easiest to maintain. :)

evincarofautumn 14y ago

I’m with you. The most rewarding thing about diving into a large codebase is that you have many opportunities to refactor while you add features. At my current job I add only marginally more code than I delete. Feels good. :)

getspeedly 14y ago
Sure -- as long as there are tests and some semblance of order. Trying to add new features to an untested ball of mud is just about the worst possible thing one can inflict on a poor programmer.
- evincarofautumn 14y ago
  Yeah, luckily, the guy I’m working with is quite good about testing. If that weren’t the case, then I’d have a different opinion…

chipsy 14y ago

I consider the big-ugly code to be a part of the learning curve - it exposes "concrete" problems of implementation, and once built, you nurse it through a few rounds of changes before a major refactor or redesign to sweep up all the new concerns. The main problem of this strategy is with other people - as soon as you have a whole team pounding away at the same piece of code, the incremental changes obscure a high-level revised view of the problem, being distributed across several minds. Descent into a ball of mud becomes the status quo. On the other hand, optimizing the source text prematurely(either via code golf or Big Architecture) is even worse since it's not even built on a stable foundation of intention, then, but on guesses or convenient hacks.

caseysoftware 14y ago

Deleted code is the easiest to maintain. :)