61–70 of 102 posts
Tech organizations value their managers in terms of their budget, headcount and being in fashion. As such the tech business model has always been about getting "good enough" results through a brute force process, possibly with the latest tech. Expertise/deep knowledge is only added/valued when the development gets stuck.
Given the number of times we have failed to learn the lesson "downloading code from untrusted sources and running it is a bad idea" -- the log4j and NPM colors fiascos spring to mind -- I think it's fair to conclude that this industry is completely incapable of learning anything, ever.
Ignoring the fact that basing ones opinion on an entire industry based on two "fiascos" seems drastic at best, who can we trust if we suddenly can't trust organizations like Apache? Do you trust the Linux Foundation? It's almost like the issue is not that code is available, but how people use the code that's available, and no one seemingly likes funding open source code.
Given the number of times we have failed to learn the lesson "downloading code from untrusted sources and running it is a bad idea" -- the log4j and NPM colors fiascos spring to mind -- I think it's fair to conclude that this industry is completely incapable of learning anything, ever.
Not only that, but we're now creating devices that depend on remote servers. It's completely obvious what the downsides to this are, yet we embrace it without question. And why are moving to apps that only work online? Networks are slow compared to desktops. Programming seems to be the art of doing the worst thing possible. Our computers are getting faster and faster, but we're relying on communications that are vast…
But there are upsides as well: the devices are usually attached to services for which the device acts as a conduit. If the service is valuable, you can sell devices and keep collecting money after first sale, driving huge margins. Didn't Hackernews post a lot of Fs in the chat for the original BlackBerry service -- one of the first devices of this kind to reach a mass audience -- once it was shut down?
Given the number of times we have failed to learn the lesson "downloading code from untrusted sources and running it is a bad idea" -- the log4j and NPM colors fiascos spring to mind -- I think it's fair to conclude that this industry is completely incapable of learning anything, ever.
Ignoring the fact that basing ones opinion on an entire industry based on two "fiascos" seems drastic at best, who can we trust if we suddenly can't trust organizations like Apache? Do you trust the Linux Foundation? It's almost like the issue is not that code is available, but how people use the code that's available, and no one seemingly likes funding open source code.
It’s almost like software is extremely complex and security is very hard in general. You’re always going to make some kind of trade off.
The problem is that we as humans don’t know how to correctly estimate risks like security risks. That means it’s not priced in when you go and ask “should I incorporate software package X into my build??”. “Should I automatically take updates from my upstream?”. There’s no good answers here either. Ultimately you need to be careful about which dependencies you take on and which ones need to be kept up with and which ones should be pinned (but even in the best case scenario issues will occur)
This five year cycle turns up very often; that seems to be about the length of time that it takes for an idea to form, ride the hype wave, sink into the trough of disillusionment, and then be replaced by a new hot thing pushed by the next generation of fresh, idealistic programmers. Usually the new hot thing is the same basic idea as the hot thing one or two generations before the current hot thing, which always starts off bright-eyed and bushy-tailed before it runs into the wall of leaky abstractions and murderous corner-cases and the stark horror of being used in the real-world for real products. Then nearly all of the trade-offs and short-comings of the older iteration of the idea come back to haunt the new thing, and the gray-haired programmers over 35 who've seen this cycle come and go time after time have a chuckle.
Sure, GoLang could learn something like "don't make things nullable" but it would be easy to say, "yes I know that, but in our case, this creates a benefit because of X"
Just like people who believe in TDD, DDD etc. they might all work, but that doesn't mean they are objectively the best way to do things in all circumstances.
I think the better target is learning how to think and analyze more effectively so we know what we are trading off more clearly.
― Georg Hegel
"order for learning to most effectively improve our state of operation"
Things don't move "most effectively" in anything. I guarantee that other engineering disciplines do not react to new tech / innovation in any sort of optimal way. People are driven to work in certain ways by all kinds of things, and mostly has to do with incentives and social reasons.
"But I very rarely see articles looking back at past languages or technological fads and looking at current trends through that lens."
There are historical surveys all over the place, even on this site.
I don't want to attack this article too hard, and the motivation to ask whether or not we are are really learning from our experiences is good, I just feel like people are more flustered by the fact that there aren't magical best practices you can memorize and apply yet, and that most human knowledge comes from experience and intuition.
I think there's a myth that rewriting software is bad, or at least a symptom of badness, and "reusing" software is ideal. But writing software is really like creating plans: plans for what the machine should do. Of course there is much room for reusing old plans as components of your new plan. But still every plan must be about what is needed at the moment, not about reusing existing plan-components. In human communi…
There's also a weird opposite myth that old software is bad, and urgently needs to be rewritten with newer paradigms.
I'm currently hired to replace a piece of extremely stable '90s software with hundreds of janky eventually consistent microservices because for some reason. That's how software must be written nowadays, and doing it that way makes it better in some unspecified fashion.
It's not at all clear what is broken and what we're trying to improve with this work. But it's top priority.
Earlier quoted context omitted.
Ignoring the fact that basing ones opinion on an entire industry based on two "fiascos" seems drastic at best, who can we trust if we suddenly can't trust organizations like Apache? Do you trust the Linux Foundation? It's almost like the issue is not that code is available, but how people use the code that's available, and no one seemingly likes funding open source code.
The NPM colors fiasco was something we should have learned not to allow to repeat -- after the left-pad fiasco. The fact that we keep stepping on rakes and getting smacked in the face like that is the problem here.
When NPM launched, and to this day, I was among the people voicing preference for the philosophy that goes into maintaining (e.g.) the Debian repositories. But some people want a package source with no gating mechanisms.
Of course there are many options for how and when to gate that lay somewhere between debian's approach and a fully unmoderated one. But when that case was made, I was informed we were old fogies out of touch with the modern pace of development. So as far as I can tell these "fiascos" as you call them are NPM operating exactly as intended.