4 ms·

but that's a dangerous mindset to start solving the problem with A far more dangerous mindset is to think that when starting the problem you are capable of pla

but that's a dangerous mindset to start solving the problem with A far more dangerous mindset is to think that when starting the problem you are capable of planning the perfect architecture up-front. Often you don't even know what the problem is. Far better to keep things coupled and simple till you know in retrospect that you need to split them out. Same goes for global state. This is a hard lesson to learn. Abstraction is seductive.

icebraining 10y ago
A far more dangerous mindset is to think that when starting the problem you are capable of planning the perfect architecture up-front. This sounds off to me; if you assume you'll need to change the architecture later on, aren't you better off starting with a decoupled system that can more easily be changed? Or are you essentially arguing for YAGNI, in the sense that decoupling upfront is potentially useless?
- grey-area 10y ago
  Yes, YANGNI. Not against all decoupling at all, but beginners tend to err on the side of too much structure.
- wtetzner 10y ago
  > aren't you better off starting with a decoupled system that can more easily be changed? I think the problem is that you don't know where the boundaries of your abstractions should be until you have a better understand of what it takes to solve the problem.
Nomentatus 10y ago
I think about making an effort to loosely couple from the start as building in flexibility, which is useful precisely because "Often you don't even know what the problem is." Flexibility isn't a commitment to any particular abstraction of the solution, on the contrary it's the ability to dump any abstractions that you care to later on with less fuss. (Of course, you can still be unwise and decouple or create modules in ways that commit you to more than you realized.) We agree that placeholder code shouldn't commit you to too much, but there are patterns that help you with that. In the parent, the original decoupling turned out to be less performant (I take it) but wouldn't hinder completing the first draft or get in the way of a rewrite with closer coupling.
- buzzybee 10y ago
  The main challenge in abstracting for flexibility is that you are competing against your text editor. If copy-paste-modify introduces fewer new sources of error than any abstraction that is near-to-hand, then you end up in a scenario where it's actually the best option, because it is clearly reusable(in the sense of, hey, I can reuse it by copying it again) and it doesn't burden you with dependencies, so you can quickly try something and then delete it if it didn't work out. And for a lot of features, first-pass attempts, learning code - that's the space you want to be in. Cheap, dumb code. This is what I started doing in the last year or two. Now my abstracted code tends to be directly motivated through refactoring the copy-paste stuff, with only a little bit of intentional architecture generated after learning that the abstraction addresses a common concern. It's a very cultivated way of developing the code - picking fruit as it turns ripe.
  - Nomentatus 10y ago
    Abstraction isn't necessarily what loose coupling is about. It's worth some thought at the beginning to structure dumb code, to reduce waste and speeding up debugging. I agree the there's a useful element of Darwinism in coding, but Modules of cheap, dumb code are better than a big ball of mud made of cheap, dumb code. However it does depend a lot on how much you like rewriting and refactoring. Most people don't seem to. If you like it a lot, which I don't think is a bad thing AT ALL (it's just not common) I can see the attraction of starting with as much dumb code as possible and evolving from there. (But beware of local maximas.) Even so, some decisions turn out to be extraordinarily hard to undo. One of my great blunders was a poor choice of data structure (too greedy with RAM it turned out.) The more experience you have, the more likely you are to sidestep those fatal early choices, of course.

icebraining 10y ago

A far more dangerous mindset is to think that when starting the problem you are capable of planning the perfect architecture up-front. This sounds off to me; if you assume you'll need to change the architecture later on, aren't you better off starting with a decoupled system that can more easily be changed? Or are you essentially arguing for YAGNI, in the sense that decoupling upfront is potentially useless?

grey-area 10y ago
Yes, YANGNI. Not against all decoupling at all, but beginners tend to err on the side of too much structure.
wtetzner 10y ago
> aren't you better off starting with a decoupled system that can more easily be changed? I think the problem is that you don't know where the boundaries of your abstractions should be until you have a better understand of what it takes to solve the problem.

Nomentatus 10y ago

I think about making an effort to loosely couple from the start as building in flexibility, which is useful precisely because "Often you don't even know what the problem is." Flexibility isn't a commitment to any particular abstraction of the solution, on the contrary it's the ability to dump any abstractions that you care to later on with less fuss. (Of course, you can still be unwise and decouple or create modules in ways that commit you to more than you realized.) We agree that placeholder code shouldn't commit you to too much, but there are patterns that help you with that. In the parent, the original decoupling turned out to be less performant (I take it) but wouldn't hinder completing the first draft or get in the way of a rewrite with closer coupling.

buzzybee 10y ago
The main challenge in abstracting for flexibility is that you are competing against your text editor. If copy-paste-modify introduces fewer new sources of error than any abstraction that is near-to-hand, then you end up in a scenario where it's actually the best option, because it is clearly reusable(in the sense of, hey, I can reuse it by copying it again) and it doesn't burden you with dependencies, so you can quickly try something and then delete it if it didn't work out. And for a lot of features, first-pass attempts, learning code - that's the space you want to be in. Cheap, dumb code. This is what I started doing in the last year or two. Now my abstracted code tends to be directly motivated through refactoring the copy-paste stuff, with only a little bit of intentional architecture generated after learning that the abstraction addresses a common concern. It's a very cultivated way of developing the code - picking fruit as it turns ripe.
- Nomentatus 10y ago
  Abstraction isn't necessarily what loose coupling is about. It's worth some thought at the beginning to structure dumb code, to reduce waste and speeding up debugging. I agree the there's a useful element of Darwinism in coding, but Modules of cheap, dumb code are better than a big ball of mud made of cheap, dumb code. However it does depend a lot on how much you like rewriting and refactoring. Most people don't seem to. If you like it a lot, which I don't think is a bad thing AT ALL (it's just not common) I can see the attraction of starting with as much dumb code as possible and evolving from there. (But beware of local maximas.) Even so, some decisions turn out to be extraordinarily hard to undo. One of my great blunders was a poor choice of data structure (too greedy with RAM it turned out.) The more experience you have, the more likely you are to sidestep those fatal early choices, of course.