[1/*] If we take the chance that a tool (compiler, linker, batch, whatever) remains working for a particular codebase after one year as a given probability p, then the chance that build remains working after x years is p^xn, where n is the number of tools used in the build.
-
-
[11/*] The "dependency culture" of modern programming has put us into a state where software requires perpetual, constant maintenance. No longer can we take a build and say "this works" and come back to it in a year. Great for job security, horrible for software quality.
Show this thread -
[12/*] As for speculation, I wonder, at least in part, if this answers the questions me and other people like me have, which is how do companies like Twitter employ thousands of developers while seemingly producing almost no additional software or improvements?
Show this thread -
[13/*] Well, if you assume that Twitter's collective codebase is a 1000+ dependency nightmare, as I assume it probably is, then the math kind of tells us the answer: the vast, vast majority of their time will have to be spent simply keeping their existing code working.
Show this thread
End of conversation
New conversation -
-
-
Haha, this is why I set all my dependencies to "latest". So every time I try to build it makes sure I am swimming upstream from maximal chance of failure.
Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
That's pretty much what it's like using webpack, yes.
-
In my personal experience, as a developer for a unit founded in the late 80s (that was a tiny part of a giant company for about 10 years), the solution is often to just vendor everything and refuse to accept updates unless they're patching major security flaws.
- Show replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.