3 ms·

> modularise the code You mean… spend more time drawing boxes and fantasising about what tech would be 'just-perfect' for that particular box? Won’t that mea

> modularise the code You mean… spend more time drawing boxes and fantasising about what tech would be 'just-perfect' for that particular box? Won’t that mean the connections between your modules start to become more important than the modules, and the work to maintain this system would only really be justifiable if the modules can be worked on in parallel?

esafak 3y ago
It means the interfaces become important and you can work on the internals in parallel.
- jameshart 3y ago
  Just like in a microfrontend or microservice architecture
  - anotherhue 3y ago
    A function boundary in a compiler is a lot easier to work with than a network boundary for a service in another repo in another language on another kernel. Those false equivalencies are what drive the cost.
- bluGill 3y ago
  Interfaces are hard. If you can avoid doing them that is a good thing (that is the interface is whatever someone who writes both sides of it wants it to be, and it changes as that person feels free). However on large projects you cannot do that, you can try but eventually some interface is used by so much that changes becomes difficult just because of the other code you need to change. (additions are easy, but if you want to change something like the arguments to an existing function that is hard just because of all the users who need to change)
  - esafak 3y ago
    Version your API, and talk to your consumers before building it so you can design an API that meets their needs. Run a pilot with at least two consumers before even announcing it.
    - bluGill 3y ago
      Those are good best practices, but they don't solve the problem. If nothing else you end up supporting a V1 API that is now very unlike how you want people to use your system. Often the pain of supporting this is so high you will just refuse to ask if the API can be improved despite the pain of the bad API.

esafak 3y ago

It means the interfaces become important and you can work on the internals in parallel.

jameshart 3y ago
Just like in a microfrontend or microservice architecture
- anotherhue 3y ago
  A function boundary in a compiler is a lot easier to work with than a network boundary for a service in another repo in another language on another kernel. Those false equivalencies are what drive the cost.
bluGill 3y ago
Interfaces are hard. If you can avoid doing them that is a good thing (that is the interface is whatever someone who writes both sides of it wants it to be, and it changes as that person feels free). However on large projects you cannot do that, you can try but eventually some interface is used by so much that changes becomes difficult just because of the other code you need to change. (additions are easy, but if you want to change something like the arguments to an existing function that is hard just because of all the users who need to change)
- esafak 3y ago
  Version your API, and talk to your consumers before building it so you can design an API that meets their needs. Run a pilot with at least two consumers before even announcing it.
  - bluGill 3y ago
    Those are good best practices, but they don't solve the problem. If nothing else you end up supporting a V1 API that is now very unlike how you want people to use your system. Often the pain of supporting this is so high you will just refuse to ask if the API can be improved despite the pain of the bad API.