4 ms·

We have a history of abstraction-based code that’s turned applications into frozen balls of mud. We have so many tools to help write good code that the short-t

We have a history of abstraction-based code that’s turned applications into frozen balls of mud. We have so many tools to help write good code that the short-term savings of shared libraries is superseded by having distinct codebases that can be modified without those dependency concerns. Same is true for finding bugs in many places and easily setting those up for maintenance releases.

kaba0 3y ago
There is no going around complexity. We are absolutely standing on the shoulders of huge giants; even if you think you don’t have any dependency, behind the scenes you use many decades-old libraries dealing with the complexity of floating point arithmetics and such. Also, Brooks paper is still true, the only real, significant productivity boost is reusing existing code. Even if you rewrite everything from scratch, you will still have to carry the exact same amount of essential complexity. Managing complexity is pretty much the most important part of CS.
- DanielHB 3y ago
  open any network communications protocol RFC or any CPU design architecture or operating systems memory tables or operating systems filesystems with journaling or hardware I/O it is crazy that society hasn't collapsed yet
DanielHB 3y ago
Some engineer from Netflix once said something along the lines: "Microservices, not too many, mostly alongside team boundaries". Meaning most microservices should be wholly owned by a team and a team should ideally own only one microservice (but exceptions are allowed under special circumstances) Like microservices, I feel code abstractions should be thought in a similar way, mostly a thing we use in our team, not company wide In my own team I have to fight very hard to keep dependencies to external code down, the amount of entangling people are willing to put their code through is just crazy. An argument I often put is: "Why should we use lib X from team Y from my company if they don't even feel it is good enough to open source?". Any external code that my team imports into our project should be good enough it could be open sourced (given IP-rights allowing)

kaba0 3y ago

There is no going around complexity. We are absolutely standing on the shoulders of huge giants; even if you think you don’t have any dependency, behind the scenes you use many decades-old libraries dealing with the complexity of floating point arithmetics and such. Also, Brooks paper is still true, the only real, significant productivity boost is reusing existing code. Even if you rewrite everything from scratch, you will still have to carry the exact same amount of essential complexity. Managing complexity is pretty much the most important part of CS.

DanielHB 3y ago
open any network communications protocol RFC or any CPU design architecture or operating systems memory tables or operating systems filesystems with journaling or hardware I/O it is crazy that society hasn't collapsed yet

DanielHB 3y ago

Some engineer from Netflix once said something along the lines: "Microservices, not too many, mostly alongside team boundaries". Meaning most microservices should be wholly owned by a team and a team should ideally own only one microservice (but exceptions are allowed under special circumstances) Like microservices, I feel code abstractions should be thought in a similar way, mostly a thing we use in our team, not company wide In my own team I have to fight very hard to keep dependencies to external code down, the amount of entangling people are willing to put their code through is just crazy. An argument I often put is: "Why should we use lib X from team Y from my company if they don't even feel it is good enough to open source?". Any external code that my team imports into our project should be good enough it could be open sourced (given IP-rights allowing)