7 ms·

So you write all that functionality that comes with the framework yourself, and then what? It doesn't need improvement? It doesn't need updating to remain compa

So you write all that functionality that comes with the framework yourself, and then what? It doesn't need improvement? It doesn't need updating to remain compatible with the ever changing technology around it? As far as I'm concerned, you're digging a hole either way, it's just the shape of the hole that changes. The bottom line is that there is too much code to maintain (or migrate, or rewrite, depending on the shape of your hole) and never enough resources/people/budget/time to do it. Everything is a huge tradeoff.

mattgreenrocks 13y ago
> The bottom line is that there is too much code to maintain (or migrate, or rewrite, depending on the shape of your hole) and never enough resources/people/budget/time to do it. Everyone says this, but then finds time for FB/Twitter/HN during the day. Something doesn't line up. This is a question of priorities, and people not feeling the effects of hard coupling to a framework.
- deleted 13y ago
  [deleted]
- x0x0 13y ago
  do you really believe that 20 minutes of time wasting on hn per day somehow translates into a significant amount of dev work that I could have done but didn't?
  - mattgreenrocks 13y ago
    20 * 5 = 100 minutes So, yes. It's OK if you don't, but I think it's worthwhile foregoing social media sometimes to work on studying and upping your game. Besides, you don't always have to be in "OMG not enough time to do this nicely!" mode. Such a mindset is reactionary and generally not conducive to writing robust code. I'd rather go a little slower and not have to return to parts of the codebase later.
    - pavel_lishin 13y ago
      Not all minutes are created equally. Spending 100 minutes in a row on code is usually pretty useful; coming back to it for 20 minutes a day is not, especially if we're talking about upgrading to a major upgrade of a framework, which we are.
      - icefox 13y ago
        I would have to second this. When I have a meeting that ends 15 minutes before lunch it is hard to want to work on a task when I know I wont be able to get into the flow.
- doktrin 13y ago
  > Everyone says this, but then finds time for FB/Twitter/HN during the day. Not to mention extravagant lunch breaks spent chewing food instead of inhaling Soylent, trips to the bathroom and time wasted milling around the proverbial water cooler. More to the point, the technical debt being discussed here isn't solved by increasing office productivity by 5%.
- iopq 13y ago
  This is why we don't do away with the 40 hour work week. Some people will always think that working more will solve all of our problems.
  - mattgreenrocks 13y ago
    Haha, not at all. I'm all for 20 hour weeks. I do believe that thinking more and working less on work will solve more problems though.
programminggeek 13y ago
You don't write all the functionality that the framework gives you. You create boundaries between the framework and your code, so that if the framework changes, your app code doesn't have to. It doesn't matter if it's a front end framework, a database ORM, a queue, or a web api. External changes don't need to break your core app.
- PommeDeTerre 13y ago
  What you propose may sound great and easy in theory, but in practice it's usually a huge disaster. The truly useful code of the application will quickly become overwhelmed by the code that tries to abstract away the high-level abstractions offered by the frameworks being used. The boundary or interfacing code you mention ends up becoming a custom framework in and of itself, but usually far more limited than the underlying frameworks. It's pointless to use a framework in the first place in order to reduce the time and effort needed to build a software system, only to immediately try to abstract it away with a bunch of custom code. As an industry, we've seen these kinds of systems in the Java world for many years now, and they never turn out well. The performance is awful due to the layers upon layers of abstraction. It becomes extremely difficult to partially, never mind fully, comprehend such a system. This in turn makes even simple changes risky and awkward. And in virtually all cases, the abstractions end up being useless, because the underlying framework is never actually changed at any time. And in the rare cases that it is, a huge amount of work is needed anyway because the code abstracting away the framework never does this perfectly. The cost of implementing and maintaining the type of abstraction that you propose can easily exceed the cost of rebuilding from scratch software systems that are highly tied to one or more frameworks.
  - petervandijck 13y ago
    Exactly. Abstraction upon abstraction upon abstraction. I still write to just write plain SQL. (They call it "raw" and it comes with warnings!). That's enough abstraction for me :)

mattgreenrocks 13y ago

> The bottom line is that there is too much code to maintain (or migrate, or rewrite, depending on the shape of your hole) and never enough resources/people/budget/time to do it. Everyone says this, but then finds time for FB/Twitter/HN during the day. Something doesn't line up. This is a question of priorities, and people not feeling the effects of hard coupling to a framework.

deleted 13y ago
[deleted]
x0x0 13y ago
do you really believe that 20 minutes of time wasting on hn per day somehow translates into a significant amount of dev work that I could have done but didn't?
- mattgreenrocks 13y ago
  20 * 5 = 100 minutes So, yes. It's OK if you don't, but I think it's worthwhile foregoing social media sometimes to work on studying and upping your game. Besides, you don't always have to be in "OMG not enough time to do this nicely!" mode. Such a mindset is reactionary and generally not conducive to writing robust code. I'd rather go a little slower and not have to return to parts of the codebase later.
  - pavel_lishin 13y ago
    Not all minutes are created equally. Spending 100 minutes in a row on code is usually pretty useful; coming back to it for 20 minutes a day is not, especially if we're talking about upgrading to a major upgrade of a framework, which we are.
    - icefox 13y ago
      I would have to second this. When I have a meeting that ends 15 minutes before lunch it is hard to want to work on a task when I know I wont be able to get into the flow.
doktrin 13y ago
> Everyone says this, but then finds time for FB/Twitter/HN during the day. Not to mention extravagant lunch breaks spent chewing food instead of inhaling Soylent, trips to the bathroom and time wasted milling around the proverbial water cooler. More to the point, the technical debt being discussed here isn't solved by increasing office productivity by 5%.
iopq 13y ago
This is why we don't do away with the 40 hour work week. Some people will always think that working more will solve all of our problems.
- mattgreenrocks 13y ago
  Haha, not at all. I'm all for 20 hour weeks. I do believe that thinking more and working less on work will solve more problems though.

programminggeek 13y ago

You don't write all the functionality that the framework gives you. You create boundaries between the framework and your code, so that if the framework changes, your app code doesn't have to. It doesn't matter if it's a front end framework, a database ORM, a queue, or a web api. External changes don't need to break your core app.

PommeDeTerre 13y ago
What you propose may sound great and easy in theory, but in practice it's usually a huge disaster. The truly useful code of the application will quickly become overwhelmed by the code that tries to abstract away the high-level abstractions offered by the frameworks being used. The boundary or interfacing code you mention ends up becoming a custom framework in and of itself, but usually far more limited than the underlying frameworks. It's pointless to use a framework in the first place in order to reduce the time and effort needed to build a software system, only to immediately try to abstract it away with a bunch of custom code. As an industry, we've seen these kinds of systems in the Java world for many years now, and they never turn out well. The performance is awful due to the layers upon layers of abstraction. It becomes extremely difficult to partially, never mind fully, comprehend such a system. This in turn makes even simple changes risky and awkward. And in virtually all cases, the abstractions end up being useless, because the underlying framework is never actually changed at any time. And in the rare cases that it is, a huge amount of work is needed anyway because the code abstracting away the framework never does this perfectly. The cost of implementing and maintaining the type of abstraction that you propose can easily exceed the cost of rebuilding from scratch software systems that are highly tied to one or more frameworks.
- petervandijck 13y ago
  Exactly. Abstraction upon abstraction upon abstraction. I still write to just write plain SQL. (They call it "raw" and it comes with warnings!). That's enough abstraction for me :)