4 ms·

Here here - In our project, its packed with generic features - most of them haven't be used ever and were released ages ago. Often they really complicate the a

by fendale 18y ago

Here here - In our project, its packed with generic features - most of them haven't be used ever and were released ages ago. Often they really complicate the application with lookup tables and weird logic that never sees the light of day, 'just incase'!

pc 18y ago
I think you mean "Hear, hear".
- fendale 18y ago
  Hear, hear indeed - It was 11pm after a long day when I wrote that, but I won't make the same mistake again, lol!
edw519 18y ago
Good example but not what I was referring to. I just finished an app with 51 separate modules, every one hard coded in infinite detail, and much of the code duplicated, 4000 LOC in all. Crazy, right? I used to think so, too. I could have written one very flexible parameter driven module in a few hundred LOC. But guess what? Even though I bitched and moaned the whole time I wrote the monster, I was able to refactor and "genericize" it in one day. Start to finish time was much shorter than if I had written the flexible module first (that is, if I had ever finished). This was a non-intuitive lesson for me. Write the specific case and extend later. I always used to try to write the most comprehensive "able to do anything" code until I realized that sometimes, the long way around is actually quicker. Thanks again Jason, for #3.
- BrandonM 18y ago
  This seems like a great idea if you are committed to immediately refactoring. The problem is that most people move onto something else as soon as they have something that works. In this case, the code becomes a maintenance nightmare until someone actually takes the time to refactor it. When immediate refactoring is unlikely (either due to laziness, lack of focus, or feature deadlines), some kind of balance has to be reached on what should be more general and reusable and what should be hard-coded and specific. And then we're right back where we started. But reading and thinking about your posts has been very insightful. On my next project, I will try your approach. I agree that in the long run, it is likely to be a more efficient use of time. I imagine, though, that someone coding in this style will either have to have a great memory or take good notes in order to know where similar code is located. Especially consider the case of generalizing the code from one project to another project.
  - edw519 18y ago
    Like I said, it wasn't easy doing it this way. Every bone in my body screamed, "What's wrong with you? Stop replicating code! Write flexible functions!" But I struggled on until everything worked perfectly. Here's the good news: I couldn't wait to refactor. I was "in the zone" the whole day. And it felt great. I finally got to clean up the mess that I made, and best of all, I didn't have to struggle trying to figure out how to handle that strange outlying case: it was all already there! I don't know if I'd try this in someone else's shop. You're right; they'd probably pull me off before I got to refactor, leaving a mess for someone else with nothing learned.

by fendale 18y ago

pc 18y ago

I think you mean "Hear, hear".

fendale 18y ago
Hear, hear indeed - It was 11pm after a long day when I wrote that, but I won't make the same mistake again, lol!

edw519 18y ago

Good example but not what I was referring to. I just finished an app with 51 separate modules, every one hard coded in infinite detail, and much of the code duplicated, 4000 LOC in all. Crazy, right? I used to think so, too. I could have written one very flexible parameter driven module in a few hundred LOC. But guess what? Even though I bitched and moaned the whole time I wrote the monster, I was able to refactor and "genericize" it in one day. Start to finish time was much shorter than if I had written the flexible module first (that is, if I had ever finished). This was a non-intuitive lesson for me. Write the specific case and extend later. I always used to try to write the most comprehensive "able to do anything" code until I realized that sometimes, the long way around is actually quicker. Thanks again Jason, for #3.

BrandonM 18y ago
This seems like a great idea if you are committed to immediately refactoring. The problem is that most people move onto something else as soon as they have something that works. In this case, the code becomes a maintenance nightmare until someone actually takes the time to refactor it. When immediate refactoring is unlikely (either due to laziness, lack of focus, or feature deadlines), some kind of balance has to be reached on what should be more general and reusable and what should be hard-coded and specific. And then we're right back where we started. But reading and thinking about your posts has been very insightful. On my next project, I will try your approach. I agree that in the long run, it is likely to be a more efficient use of time. I imagine, though, that someone coding in this style will either have to have a great memory or take good notes in order to know where similar code is located. Especially consider the case of generalizing the code from one project to another project.
- edw519 18y ago
  Like I said, it wasn't easy doing it this way. Every bone in my body screamed, "What's wrong with you? Stop replicating code! Write flexible functions!" But I struggled on until everything worked perfectly. Here's the good news: I couldn't wait to refactor. I was "in the zone" the whole day. And it felt great. I finally got to clean up the mess that I made, and best of all, I didn't have to struggle trying to figure out how to handle that strange outlying case: it was all already there! I don't know if I'd try this in someone else's shop. You're right; they'd probably pull me off before I got to refactor, leaving a mess for someone else with nothing learned.