4 ms·

Right; breaking it up doesn't necessarily make it more modular, it just necessarily spreads it around. This is -a bad thing-, with no other context. The hope is

Right; breaking it up doesn't necessarily make it more modular, it just necessarily spreads it around. This is -a bad thing-, with no other context. The hope is that it modularizes the code enough to enable better understanding/reuse/extension (thus being a necessary evil).

josephg 5y ago
Right. The problem I've seen way too much is modularizing code too early in its lifecycle. This mistake seems to happen a lot by smart programmers who are inexperienced. The instinct seems to be that they want hinges in their code, so their code can adapt and be reusable between projects. But they don't actually know where the hinges should go, because they don't need them yet. So they just put hinges all over the place - even where hinges aren't useful. If the metaphor is confusing, I'm talking about things like making an interface around a class, when there's only one implementor of that interface anyway. Or breaking a complex function into small, "reusable" pieces spread over multiple files - except where those small pieces are only ever used by that one call stack anyway. (And where they aren't that semantically self contained.) The result is harder to follow code with no actual benefit. And the resulting code is almost always bigger and more complex, and thus harder to work with. Usually code thats the easiest to refactor is code thats the easiest to understand. That means, small, dense, correct code, with a simple test suite. If you write code knowing that you can (and will refactor) later anyway, the result is almost always better software. You will come up with a better design after you know more about your problem domain. Plan for that, and set yourself up to take advantage of that knowledge later.
- deltasixeight 5y ago
  > Right. The problem I've seen way too much is modularizing code too early in its lifecycle. This mistake seems to happen a lot by smart programmers who are inexperienced. I don't see this as bad. Modularization protects against an uncertain future. Most code that's modularized is only used once and this Looks bad only because you haven't seen the alternative of what could have happened if code wasn't modularized. Non modularized code is often designed wrong because of an uncertain future. Once the project is too far down the line, people just keep piling technical debt on top of the design flaw. Code is rarely rewritten until it's at a point where it's horrible than it takes a massive engineering effort to rewrite and even this rewrite could be wrong. The alternative is code littered with modules that are used once. Which is better? Obviously the more modular code.
  - josephg 5y ago
    > Code is rarely rewritten until it's at a point where it's horrible than it takes a massive engineering effort to rewrite and even this rewrite could be wrong. This is your problem, right here. Your instincts know when refractors and rewrites are appropriate. But if you live in a corporate culture where those things are never allowed to happen, of course you’re going to run into problems. Premature modularity is a poor man’s substitute for simple-then-refactor. It’s not a good process.
    - deltasixeight 5y ago
      >This is your problem, right here. Nah. There's no problem here. This is the most common behavior in any place corporate or not. Humans resist change. However specifically for corporations, it is very very very rare for a company to allow a rewrite because of two reasons: First the company is often way to busy with creating features and solving problems then to do a code rewrite. Second it is in direct conflict with the bottom line. Business people don't see the necessity so there is huge resistance. When a company allows a rewrite it's 99% of the time only to serve a new feature or fix a flaw that no longer can be ignored. >Premature modularity is a poor man’s substitute for simple-then-refactor. Do you have any evidence to back up your claim or is this just your opinion? Using words like "poor mans substitute" doesn't lend any credibility to your claim. For example I can say the opposite and we can go in circles forever: Writing unmodular code is a garbage technique only done by junior developers who can't abstract things and by a good number of senior developers who've never learned how to code properly in a modular way. These guys don't even understand the true meaning of a module. See what I did there?
      - josephg 5y ago
        > There's no problem here. This is the most common behavior in any place corporate or not. Its hard to say statements like that universally because it really depends on where you work (and have worked). There are plenty of places which make time to refactor along the way, in small and large ways. Its good engineering, and a healthy code base nets better long term outcomes for the business too. Business people care about the team's velocity (since programmers are expensive). And I'm disheartened you think its the norm but not all companies have MBAs telling software engineers how to do our jobs. (Eg, Google / Facebook / Netflix / Github / etc.) > Do you have any evidence to back up your claim or is this just your opinion? Its just my professional opinion, backed up by almost 30 years writing software at all sorts of companies and in all sorts of environments. But no, I wish we had quantitative evidence for this stuff. But there's a weird dearth of quantitative research around software engineering. We as an industry don't really know what we're doing yet. I'd love to read some studies on this stuff if you can find any. But I'm very confident about what works best for me, from trying lots of things on solo projects. I'm way more productive when I throw something together quickly, iterate like mad on how it works internally, then tidy it up and modularize as I get more confident around the best way to structure the code. Whenever I modularize up front I basically always end up regretting my abstraction boundaries - and either have to rework them (which is expensive) or I leave them alone, and just ship vaguely mediocre code. But if prematurely modularizing your code is the only way you can modularize anything at your workplace then - well, you do you. But I find that pretty sad.
deltasixeight 5y ago
If you can move your code and spread it around it is Modular by definition. This is never a bad thing from a design perspective. It is only a bad thing from a complexity and readability perspective. More likely you think it's a bad thing because your code isn't actually modular. Likely you need one piece of logic but that logic isn't modular so to move it to another location you need to drag a bunch of extra baggage around with it. You wanted a banana but instead you got the gorilla holding the banana and the entire jungle. Sound familiar? The smallest primitive that is modular is a pure immutable function. If the modules you are moving around are not pure functions then likely your code isn't actually modular.
- sam0x17 5y ago
  > If you can move your code and spread it around it is Modular by definition. For it to be truly modular, you also need to be able to use it in multiple contexts. I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. What I'm saying is there are tons of times when people do this merely to get the linter to pass, instead of for the actual purpose of modularization.
  - Jtsummers 5y ago
    Right. If A and B are coupled so tightly that one cannot exist without the other, you don't really have two modules. You have one, AB. This is a common problem with improper application of the idea of modularity as well as OO concepts (in particular, breaking things into classes and thinking it creates a module). The latter is particularly pernicious in languages which don't have a clear separation between classes and modules (Java, for instance, or historically I think this has changed). The reality is that there are two (at least) kinds of modularity. "Syntactic" (I need a better name for this) modularity like Java classes, or C's translation units (why I need a better name). These act as modules, but don't necessarily define a real, proper module. And then there are your real modules which are comprised of the things that must exist together (like in the earlier example), regardless of the project structure or language's notion of a module. I had a team try to convince me their code was "modular" but their GUI portion was directly tied to the DB portion and other logic. Nothing could be instantiated separately, so it wasn't really modular, it was just using the language and build system's notions of modules to create the illusion of modularity (C++ and VS in their case). In contrast, another team had developed a collection of libraries (C# and VS again) that were used in multiple applications. That was real modularity.

josephg 5y ago

Right. The problem I've seen way too much is modularizing code too early in its lifecycle. This mistake seems to happen a lot by smart programmers who are inexperienced. The instinct seems to be that they want hinges in their code, so their code can adapt and be reusable between projects. But they don't actually know where the hinges should go, because they don't need them yet. So they just put hinges all over the place - even where hinges aren't useful. If the metaphor is confusing, I'm talking about things like making an interface around a class, when there's only one implementor of that interface anyway. Or breaking a complex function into small, "reusable" pieces spread over multiple files - except where those small pieces are only ever used by that one call stack anyway. (And where they aren't that semantically self contained.) The result is harder to follow code with no actual benefit. And the resulting code is almost always bigger and more complex, and thus harder to work with. Usually code thats the easiest to refactor is code thats the easiest to understand. That means, small, dense, correct code, with a simple test suite. If you write code knowing that you can (and will refactor) later anyway, the result is almost always better software. You will come up with a better design after you know more about your problem domain. Plan for that, and set yourself up to take advantage of that knowledge later.

deltasixeight 5y ago
> Right. The problem I've seen way too much is modularizing code too early in its lifecycle. This mistake seems to happen a lot by smart programmers who are inexperienced. I don't see this as bad. Modularization protects against an uncertain future. Most code that's modularized is only used once and this Looks bad only because you haven't seen the alternative of what could have happened if code wasn't modularized. Non modularized code is often designed wrong because of an uncertain future. Once the project is too far down the line, people just keep piling technical debt on top of the design flaw. Code is rarely rewritten until it's at a point where it's horrible than it takes a massive engineering effort to rewrite and even this rewrite could be wrong. The alternative is code littered with modules that are used once. Which is better? Obviously the more modular code.
- josephg 5y ago
  > Code is rarely rewritten until it's at a point where it's horrible than it takes a massive engineering effort to rewrite and even this rewrite could be wrong. This is your problem, right here. Your instincts know when refractors and rewrites are appropriate. But if you live in a corporate culture where those things are never allowed to happen, of course you’re going to run into problems. Premature modularity is a poor man’s substitute for simple-then-refactor. It’s not a good process.
  - deltasixeight 5y ago
    >This is your problem, right here. Nah. There's no problem here. This is the most common behavior in any place corporate or not. Humans resist change. However specifically for corporations, it is very very very rare for a company to allow a rewrite because of two reasons: First the company is often way to busy with creating features and solving problems then to do a code rewrite. Second it is in direct conflict with the bottom line. Business people don't see the necessity so there is huge resistance. When a company allows a rewrite it's 99% of the time only to serve a new feature or fix a flaw that no longer can be ignored. >Premature modularity is a poor man’s substitute for simple-then-refactor. Do you have any evidence to back up your claim or is this just your opinion? Using words like "poor mans substitute" doesn't lend any credibility to your claim. For example I can say the opposite and we can go in circles forever: Writing unmodular code is a garbage technique only done by junior developers who can't abstract things and by a good number of senior developers who've never learned how to code properly in a modular way. These guys don't even understand the true meaning of a module. See what I did there?
    - josephg 5y ago
      > There's no problem here. This is the most common behavior in any place corporate or not. Its hard to say statements like that universally because it really depends on where you work (and have worked). There are plenty of places which make time to refactor along the way, in small and large ways. Its good engineering, and a healthy code base nets better long term outcomes for the business too. Business people care about the team's velocity (since programmers are expensive). And I'm disheartened you think its the norm but not all companies have MBAs telling software engineers how to do our jobs. (Eg, Google / Facebook / Netflix / Github / etc.) > Do you have any evidence to back up your claim or is this just your opinion? Its just my professional opinion, backed up by almost 30 years writing software at all sorts of companies and in all sorts of environments. But no, I wish we had quantitative evidence for this stuff. But there's a weird dearth of quantitative research around software engineering. We as an industry don't really know what we're doing yet. I'd love to read some studies on this stuff if you can find any. But I'm very confident about what works best for me, from trying lots of things on solo projects. I'm way more productive when I throw something together quickly, iterate like mad on how it works internally, then tidy it up and modularize as I get more confident around the best way to structure the code. Whenever I modularize up front I basically always end up regretting my abstraction boundaries - and either have to rework them (which is expensive) or I leave them alone, and just ship vaguely mediocre code. But if prematurely modularizing your code is the only way you can modularize anything at your workplace then - well, you do you. But I find that pretty sad.

deltasixeight 5y ago

If you can move your code and spread it around it is Modular by definition. This is never a bad thing from a design perspective. It is only a bad thing from a complexity and readability perspective. More likely you think it's a bad thing because your code isn't actually modular. Likely you need one piece of logic but that logic isn't modular so to move it to another location you need to drag a bunch of extra baggage around with it. You wanted a banana but instead you got the gorilla holding the banana and the entire jungle. Sound familiar? The smallest primitive that is modular is a pure immutable function. If the modules you are moving around are not pure functions then likely your code isn't actually modular.

sam0x17 5y ago
> If you can move your code and spread it around it is Modular by definition. For it to be truly modular, you also need to be able to use it in multiple contexts. I could take any random 5 lines of a complex function and pull it out into another function in another file, but that doesn't guarantee that this was a smart thing to do in that particular scenario. What I'm saying is there are tons of times when people do this merely to get the linter to pass, instead of for the actual purpose of modularization.
- Jtsummers 5y ago
  Right. If A and B are coupled so tightly that one cannot exist without the other, you don't really have two modules. You have one, AB. This is a common problem with improper application of the idea of modularity as well as OO concepts (in particular, breaking things into classes and thinking it creates a module). The latter is particularly pernicious in languages which don't have a clear separation between classes and modules (Java, for instance, or historically I think this has changed). The reality is that there are two (at least) kinds of modularity. "Syntactic" (I need a better name for this) modularity like Java classes, or C's translation units (why I need a better name). These act as modules, but don't necessarily define a real, proper module. And then there are your real modules which are comprised of the things that must exist together (like in the earlier example), regardless of the project structure or language's notion of a module. I had a team try to convince me their code was "modular" but their GUI portion was directly tied to the DB portion and other logic. Nothing could be instantiated separately, so it wasn't really modular, it was just using the language and build system's notions of modules to create the illusion of modularity (C++ and VS in their case). In contrast, another team had developed a collection of libraries (C# and VS again) that were used in multiple applications. That was real modularity.