Prime Reacts: Software Engineering is In Decline

Sdílet
Vložit
  • čas přidán 18. 02. 2023
  • Recorded live on twitch, GET IN
    / theprimeagen
    MY MAIN YT CHANNEL: Has well edited engineering videos
    / theprimeagen
    Discord
    / discord
  • Věda a technologie

Komentáře • 669

  • @DaLoler1
    @DaLoler1 Před rokem +1353

    "Do you really want people who write JavaScript to be controlling your house" made me laugh harder than it should

    • @NatSPlay
      @NatSPlay Před rokem +65

      It literally encapsulates the talk though

    • @chessthoughts
      @chessthoughts Před rokem +10

      @@NatSPlay good pun.... It threw me for a loop

    • @nexovec
      @nexovec Před rokem

      DIES IN NODERED

    • @kurtnelle
      @kurtnelle Před rokem +27

      OR the flight control software for the airplne you're on.

    • @NatSPlay
      @NatSPlay Před rokem +11

      @@kurtnelle spacex used chromium for their rocket controls inside the dragon capsile

  • @jonnyso1
    @jonnyso1 Před rokem +460

    The possibility of just patching your broken software latter is really what created this whole scenario, you're absolutely right. My personal big complaint about modern software is the mentality that there are more resources available now therefore its ok to write wastefull garbage. I hate it whenever someone says "memmory is cheap", "storage is cheap" bs.

    • @ThePrimeTimeagen
      @ThePrimeTimeagen  Před rokem +104

      totally agree

    • @tablettablete186
      @tablettablete186 Před rokem

      "Processing power is cheap" 🥲

    • @ade8890
      @ade8890 Před rokem +53

      Well memory is cheap, but that isn't a justification to write buggy code that leaks. If somebody wanted to nit pick space complexity over a few bytes, I would definitely rebut with "Memory is cheap", hah.

    • @nibblrrr7124
      @nibblrrr7124 Před rokem +24

      ​@@ade8890 Agreed. Though there is that anecdote about engineers purposefully deciding to write code that leaks, since they did a calculation that long before it will become a problem, the program will have stopped running - because it was running on a military missile that will have exploded by then. :^)

    • @BTrain-is8ch
      @BTrain-is8ch Před rokem +18

      No one has that mentality. A huge part of the job of a software developer is balancing the tradeoffs. In situations where resources aren't really a constraint the simplest, cheapest, and most importantly most effective choice for the business frequently isn't the elegant, clever solution that you spent three weeks working on because the quick and dirty option wasn't optimal when the original schedule budgeted for two days.
      There's also a huge difference between going out of one's way to write garbage (something I'd wager most devs do not have the skill to do intentionally) and understanding that customer requirements are the ultimate arbiter of what is or isn't acceptable. Not your sense of professional pride.

  • @MatiasKiviniemi
    @MatiasKiviniemi Před 4 měsíci +8

    The missing perspective in this is IMO that software has become massively more complex and pervasive, doing much more things for us. Software used to be for trained specialists only that learned how it's supposed to be used, doing some mission critical worth (that justifies the expenditure). Now software is used by everybody everywhere (all at once) ofr purposes that were out of question. The correct perspective IMO is that the cost of software (both development and execution) has plummetted, allowing it to be used elsewhere. He's comparing the banking software of old to fart apps in appstore. The banking software (doing transactions in the backend) is still pretty reliable.

  • @asdqwe4427
    @asdqwe4427 Před rokem +290

    I think he has rose coloured glasses on when he thinks of the quality of the past. Sure chromium apps hog a tone of memory and are sluggish at times. But back in the nineties and 2000s when more desktop apps were c/c++, they would constantly crash and take my computer down…

    • @NostraDavid2
      @NostraDavid2 Před rokem +67

      BSOD used to happen weekly. Now it's once or twice a year, if not less.

    • @asdqwe4427
      @asdqwe4427 Před rokem +6

      @@NostraDavid2 exactly

    • @olegsilkin8507
      @olegsilkin8507 Před rokem +6

      @@NostraDavid2 My computer definitely blue screens once a week at least, a few times a day on a bad day. But I agree that things have become more stable overall.

    • @arsnakehert
      @arsnakehert Před rokem +16

      Doesn't this have to do with the architecture of older operating systems more than the quality of the software they ran? I'm not saying software wasn't buggy back then, but operating systems certainly seem to have become more secure in the sense of not allowing one application to crash the whole computer

    • @asdqwe4427
      @asdqwe4427 Před rokem +7

      @@arsnakehert that’s part of it, for sure. But I would also argue that it doesn’t change my point of old software not being better.

  • @altrag
    @altrag Před 8 měsíci +23

    This is trivially explained by the classic triangle:
    good
    / \
    fast -- cheap
    We've collectively chosen to focus on the bottom pair. We (end users) want everything right now and we don't want to pay for it. That implies sacrificing quality.
    But it depends on the demand. Military projects for example tend to focus on the left pair and ignore the cost. Space organizations and other scientific endeavors often focus on the right pair and spend years or decades making damned sure they get it right as its very difficult to fix a broken satellite. Medical equipment tends to focus on the top item exclusively and somewhat balances across the bottom pair, leading to quality software that's neither super cheap nor super fast, but also does eventually release and isn't prohibitively expensive.
    As the old saying goes, there's no free lunch. Of course one can argue that focusing on "fast" and "cheap" to the detriment of quality is an indication of the idea of "decadence" that we often attribute to the downfall of older civilizations (primarily Rome). I'm not sure that's really valid but its at least an angle to take if you want to assert that having to restart your browser periodically is the big indicator of imminent societal collapse (as opposed to say population growth - or population shrinkage depending on your fears, climate change, the recent push to revitalize authoritarianism, or any of the other problems in the world that have little to do with computers at all, hardware or software).

    • @ZoraAlven
      @ZoraAlven Před 3 měsíci

      Jesus Christ said, that there should actually be a free lunch.

  • @cherubin7th
    @cherubin7th Před rokem +9

    Y Combinator always recommends to ship your Minimal Viable Product as fast as possible even if half broken.

  • @rolandinnamorato1953
    @rolandinnamorato1953 Před rokem +212

    Half baked software is everywhere and it's a welcome surprise when it works as intended.

    • @timothyvandyke9511
      @timothyvandyke9511 Před rokem +2

      agreed

    • @PorthoGamesBR
      @PorthoGamesBR Před 8 měsíci +9

      Mostly because people can't see the true cost of software not working. A simple reestart dont cost that much on its own, maybe a couple of seconds or minutes, but if you sum it during days, months or years of work, you start to notice how much time you lost just waiting for Adobe Premiere to reestart after it crashed during rendering

    • @altrag
      @altrag Před 8 měsíci

      @@PorthoGamesBR We can see it, but we have to relate it to the cost of software working. If you're OK with the next update to Premiere dropping in 5 years and costing $10,000 annually I'm sure Adobe can make it rock solid.
      But of course nobody would wait for that or pay for it. They'll just switch to the shitty clone that costs $100 for a "permanent" license and deal with having to restart every few days. Just fire off a message to the developer and you'll have a fix within a few months or maybe even weeks, not a half decade.
      Developers _could_ do better but there's no incentive for it. They'd lose more customers trying to account for the additional costs and delays than they'd make through the good PR of a "rock solid product".
      If we want good software, we need to incentivize developers to make good software. Whining about it on the internet isn't sufficient - we need to put our money where our mouths are. A lot of money thanks to the 80/20 rule. That last 20% of bugs will (on average) cost 4x more to fix relative to the first 80%.
      That's commercial software of course. You might think it doesn't apply to FOSS because there's no cost and 4x0 is still 0. I'd argue that's incorrect. You may not have the dollar cost but there's still the time cost - some developer somewhere needs to put in 4x more of their time in order for those last 20% of bugs to get fixed. That's a lot to ask of someone who is unpaid and only working on the project out of passion. Nothing kills passion like grinding away at some rare problem somebody else has that you can't reliably reproduce. They just won't do it. They'll spend their time adding a new shiny feature instead. New features draw more interest from the public and are less demotivating for the developer. Of course they'll put their time there.

    • @jewelsbypodcasterganesh
      @jewelsbypodcasterganesh Před 6 měsíci +1

      Even on sites like CZcams and Facebook there's obvious, unfixed bugs.

    • @altrag
      @altrag Před 5 měsíci

      @@davefunk135 Yeah there's a terminology clash there. "Developer" can either mean the company as a whole, or an individual worker.
      You just have to use your best judgement from context and not blindly assume I'm implying some singular person is responsible for all of the bugs in all of the products Adobe sells.

  • @Pavel-wj7gy
    @Pavel-wj7gy Před rokem +462

    Also, the notion that old software was not breaking is just bizarre. It was giving exactly the errors like in Jonathan's Visual Studio example more often than today. I used to have a Celeron PC in 2000s that would eject/insert CD-ROM, like, 4 times on every reboot just for the heck of it. There wasn't even a disc inside that CD-ROM.

    • @rafaelbordoni516
      @rafaelbordoni516 Před rokem +51

      I was thinking the same thing too, like, on the whole talk he showed a clip of the guy who wrote Unix telling the story of how it came to be and it was like, in 2 weeks he went from nothing to having Unix. However, OSs were way simpler back then, computers have a lot of new hardware that must be working off the box today. However I stopped to think: back then computers were only for programmers. Today, people use software to work almost every job, we use software to buy stuff, to do our banking, to communicate... Civilization just depends way harder on software today. Not to say he is 100% right, it's just something to think about.

    • @erifetim
      @erifetim Před rokem +36

      Not to mention that Jon says in his talk that GMail makes the same mistakes that Microsoft Word did in the 90s and 2000s

    • @crackasaurus_rox9740
      @crackasaurus_rox9740 Před rokem +10

      @@rafaelbordoni516 Take a look at reviews for any new product and you will find that users only care about maybe 5% of the software features. People don't rely upon software that does everything because they choose to. They do it because developers force them too. All of these features are useful to someone, but most are merely a distraction to everyone, including the developers. Thing is, developers don't develop for the users anymore. They develop for themselves. The users are just along for the ride.

    • @nordgaren2358
      @nordgaren2358 Před rokem +11

      2000s is past the time he was talking about. He specifically said when developers started relying on just pushing updates, and 2000s is def past that time-frame.

    • @huckleberryfinn8795
      @huckleberryfinn8795 Před rokem +11

      Exactly!! We just use software SOOO much more compared to 30, 20 or 10 years ago so it SEEMS like it happens more frequently, which it does. But if we increase the number of cars on the road 10 fold, then the total number of car accidents will also increase. Basic math really.

  • @SpookySkeleton738
    @SpookySkeleton738 Před rokem +14

    Hit the nail on the head with the problem surface comment. Casey Muratori made a talk about this, the real source of the problem is that while in the 80s and early 90s you were programming for MS-DOS on IBM PC, you're now programming for like 4 different software platforms on a theoretically infinite number of janky hardware configurations. The problem honestly, really begins with the fact that we're not working with a stable hardware ISA to begin with.

  • @ericwalker8382
    @ericwalker8382 Před rokem +21

    Yes, sacrificing code efficiency because the hardware is better is exactly what he means. Database developers have been doing the same thing because "storage space is cheap" until it isn't. Processing speed is cheap until it isn't. I 100% understand what he is talking about.

  • @rafaelbordoni516
    @rafaelbordoni516 Před rokem +61

    The whole talk is very interesting. This clip is just a funny part of the talk, but the important stuff was left out. I think it's also important to understand that Jon Blow is a game dev, and the game dev world is very different from web dev, optimization is waaaay more important there. If you know game dev, worked with engines and stuff and go play video games, especially small indie games, you'll see so much suboptimal stuff that it gets to your head. Lots of tutorials teach you stuff that work on the surface but perform really badly on the whole project, when it is feasible to do on bigger scale. Engines do 99% of the work right now in game dev and most programmers don't understand what the engine is doing under the hood (I know I don't...). And even though engines are powerful, they are generic tools so if you were to use a specialized tool to make your game, you could make it better with less bugs. Not to say that in web dev people know their shit, but that's kinda the point: working in game dev makes you more aware of how much better software could be, and today we do everything with software. Back then, when software was simpler, it was just a niche tool only programmers could use. We now use it to communicate, work, be entertained, get transported, our whole civilization depends on it. Not to say he is right about our civilization collapsing, but he definitely has a point.

    • @prestonrasmussen1758
      @prestonrasmussen1758 Před rokem +4

      I agree that game dev and web dev are different. I disagree however, that "optimization is waaaay more important" in game dev than it is in web dev. I think the optimizations are different, and in web dev the optimizations that are happening are even more abstracted away from the end user, so its more difficult for a non-expert to understand or even ntoice that it's happening.
      For example, game dev for offline games is about optimizing local resources. it's about doing things like 3D vector calculations using as few clock cycles of the GPU as possible. However, don't have to worry about 100 people trying to use resources from the same GPU at the same time.
      Web dev on the other hand has optimizations around distributed systems, databases with immense amounts of data, and thousands or millions of users making concurrent requests. I saw Jonathan Blow brag about how is program has to handle "gigabytes of data every second" like it was a large amount of data. If you type in a Google search bar it has to be able to return results from a database millions of times that size in a handful of milliseconds. Furthermore, game dev runs on 60-120 FPS and so reducing a process by a handful of milliseconds will often be a meaningful optimization. However, for web dev if the data you're returning is going to take 100 ms to travel over the internet anyways, sacrificing accuracy to improve a search by 5 ms is not a worthwhile tradeoff. So the optimizations are different in web dev, but they are also some of the hardest problems in human history to solve.
      The issue you bring up with engines is present in web dev too. Engines abstract away a lot of functionality and optimizations in game dev, and frameworks and cloud services do the same thing in web dev.

    • @rafaelbordoni516
      @rafaelbordoni516 Před rokem

      ​@@prestonrasmussen1758 You realize all of those are also a game dev thing, right? You also have to optimize request times with millions of users sending requests, especially because each frame your requests lags can make or break your game. It's to the point where a modern game like Smash Ultimate has its community limiting online tournaments to only people in the same region to save a few frames, but overall they avoid online tournaments altogether.
      You are right about optimizing this stuff being hard and important, maybe "important" wasn't a good choice of word. I meant to say it's more impactful to a typical game than to a typical web app. It's easier to tank your performance in UE4 or Unity than at a NextJS React app, at least to the point of making users complain. I'm not sure about which is more abstracted tbh. I'm only your typical TypeScript+React+Express bootcamp summer child at web dev, and at game dev I only know Godot and Unity and in my experience, these two engines abstract way more than the web dev stuff but opinions may differ.

    • @prestonrasmussen1758
      @prestonrasmussen1758 Před rokem +4

      @@rafaelbordoni516 Notice I explicitly said for “offline games.” But in any case, the large websites are still handling much larger user bases than the large games. And the people handling the infra for games are also infra devs.
      Also when I talked about web dev stuff being more abstracted than offline games, I was meaning that you not only have a framework that abstracts software, but the cloud deployment means you’re also abstracting the hardware, so it’s not just the hardware sitting in front of you that’s running the code.

    • @jakubrogacz6829
      @jakubrogacz6829 Před rokem

      yeah. I have enough time to run full map djikstra search ( tanks frames for a second or too but is largely invisible, while former implementation tanked to 1-2 FPS due to draw call ammount (and fun stuff is that technically I still don't know why batching tile layers drops draw calls by three magnitude orders ( thing is I use atlas anyway so probably there is some error mine or in library which rebinds already bound texture ).

  • @remssi-dev
    @remssi-dev Před rokem +31

    One thing that is adding to all this is the commercial side. "Just push Minimum Viable Product out there fast and iterate on that"
    Also, of course people let more buggy apps slide when it is just an annoyance and not literally going to get someone killed. It depends on the needs of the application (and business).

  • @ieternalsyn
    @ieternalsyn Před rokem +13

    "Do you really want people who are writing Javascript to control your house?" Instantly liked lmao

  • @Anteksanteri
    @Anteksanteri Před rokem +93

    Prime also watched the Casey Muratori optimization lecture. The complexity thing has to do with both of these. Casey and Jon know eachother and worked together on The Witness. Having watched most of both their highlights on youtube, I think an assumption that they both make is that almost always it would be better to use less abstraction and severely limit your use of external libraries when trying to make performant, high quality software. The most important argument is that you're using the right tool for the right job, and it's your job as a developer to make the right tool, which is often far simpler than people think of and supports deep understanding of how your system actually works, instead of handwaving library calls. Here's a comparative list of the pros and cons I wrote yesterday:
    writing your own implementation
    +/- requires studying the problem domain
    + if done well, eliminates complexity
    - takes time
    - result might not be the highest quality
    - changing requirements make using an existing library seem attractive
    +/- this is the careful approach
    using an existing library
    - you might have unknown invisible dependencies on e.g. system state
    - requires learning
    + the interfaces can be better limited to your problem domain
    + having other people maintain non-trivial changes is ideal (like graphics drivers or something)
    + more time working on the non-trivial parts of your program
    + quicker to market
    - risky, though the risk can be mitigated through reasoning that you actually need to write your own implementation
    - cheaper in the short term
    - external dependencies can lead to your program having uncontrollable technical debt.
    - you might not understand what you are depending on
    - often the thing you need doesn't really exist or it doesn't match some quality you are looking for.
    suggested strategies to deal with this
    if possible, question what is the maximum possible problem domain it may affect
    e.g. some enemy movement script vs enabling operator overloading for your new programming language through some library
    popularity can be good, but is not a guarantee of quality
    avoid bloating your dependencies without reason
    understand what you actually need
    be critical of any new libraries
    at least review what it is
    very often the thing you use is not as complicated as you may thing.
    (case and point, JS libraries that are like 10 lines and downloaded a 300k times)
    it's possible to pivot from an existing library to your own sometimes, if need be.
    unit tests for this are actually really useful
    every part of your program that uses and is covered works
    if the thing already has unit tests you may pick the subset that applies to your problem domain and perhaps translate them to use the new interfaces

    • @itr00ow93
      @itr00ow93 Před rokem

      where can I find it?

    • @odysseasragnarson7295
      @odysseasragnarson7295 Před rokem

      have a link to that?

    • @Anteksanteri
      @Anteksanteri Před rokem

      @@odysseasragnarson7295 It's at 1:41:20 in this vod: www.twitch.tv/videos/1738012731?filter=archives&sort=time

    • @Anteksanteri
      @Anteksanteri Před rokem

      @@itr00ow93 check the replies now :)

    • @itr00ow93
      @itr00ow93 Před rokem

      @@Anteksanteri I don't see it?

  • @laggmonkei
    @laggmonkei Před rokem +81

    Its unfortunate that his example with photoshop startup wasn't included because that is the best point regarding all this imo. In the last 20 years when hardware has become almost infinitely faster the loading time is slower than before.
    Hardware advances has covered up so much of the software performance ignorance that it's ridiculous.

    • @officiallyaninja
      @officiallyaninja Před rokem +11

      And photoshop today can do so much more than photoshop 20 years ago. It's not slow because the programmers and incompetent it's slow because it's big and complex and they can't afford to spend more dev hours on load times.

    • @saniel2748
      @saniel2748 Před rokem +34

      @@officiallyaninja Does Photoshop do anything it didn't do before on startup tho? It really doesn't, and there is no need to make me wait a minute so you can load all your fancy plugins if all I want is to crop the image

    • @edd9581
      @edd9581 Před rokem +6

      ​@@saniel2748 Imagine if photoshop only load the features that the user sees on the screen at start

    • @La0bouchere
      @La0bouchere Před rokem +26

      @@officiallyaninja Except that there are games that are more complex than photoshop, developed in 1/30th the amount of time, with less resources, that handle full ray tracing at 60 fps.
      Besides, long load times are usually caused by poor architectural planning, not a lack of dev time.

    • @nikhiljugdan724
      @nikhiljugdan724 Před rokem +14

      @@officiallyaninja Adobe, a multi billion dollar compay can't afford to improve load times. Yeah, no one is going to buy that.

  • @Kerngebruiker
    @Kerngebruiker Před rokem +9

    When I moved from some undefined variant of XP to religious SCRUM the thing I noticed most was the preference of teams for new features over bugs. It really takes a good product owner or spam of bug reports about the same thing to get things moving along.

  • @valhalla_dev
    @valhalla_dev Před rokem +178

    Describing Jonathan as grumpy is an incredibly accurate and generous statement. He's got some good takes and he's wicked smart in some areas but boy can he get grumpy.

    • @timothyvandyke9511
      @timothyvandyke9511 Před rokem +11

      I would say "Jaded" tbh

    • @xunjin8897
      @xunjin8897 Před rokem +18

      The problem here is not being grumpy, is being disconnected from reality. Primeagen nailed 2 points:
      - the fact that you can update software made you rethink your strategy of deploy.
      - How much the scope has grow in layers of indirection and usages.
      Looking at how things were and what we can learn from the past is good, however saying the future is doomed because things are not how it was in the past, is a childish take.

    • @gocryptoyourself2423
      @gocryptoyourself2423 Před 11 měsíci

      Smart people are angry because they see all the stupid shit.

    • @Lazlo-os1pu
      @Lazlo-os1pu Před 7 měsíci

      @@xunjin8897it’s also the fact that we use software constantly and for everything these days. More time spent using software naturally means you’re going to come into contact with more issues with it. Yet the fact that we use software so much suggests that software is in fact thriving rather than dying.

    • @MrLordFireDragon
      @MrLordFireDragon Před 7 měsíci +13

      ​@@xunjin8897
      The point isn't "Things aren't the same", it's "Things are worse, and not because we're getting gains in other areas".
      During the whole "But look at how much surface area a program has now!" I could not stop thinking that Blow would immediately say "Yes, and that's a problem". The fact we have so many pieces of software relying on each other, each of which was not developed rigorously, is a problem. It indicates a lack of software development improvement which accounts for this interconnectedness. We keep developing new things without making the things we already have work rigorously, and this house of cards inevitably gets more fragile.
      Similarly, the ability to perpetually patch and update software is not some unilaterally good thing we just have to accept because of how good it is, and therefore accept that worse software is now the norm.

  • @illicity2383
    @illicity2383 Před rokem +12

    Okay @ThePrimeTime. I have a theory that might explain this better. What if software is crappier nowadays because of simple capitalism!? I'm a full stack developer. I have NEVER worked with a client that didn't have a rushed timeline, or poor budget. Companies want software fast, and cheap. I think thats why we have so many issues with software nowadays.

    • @barreltitor1419
      @barreltitor1419 Před 7 měsíci +4

      This ^
      Pretty much what prev devs and my boss did at my prev employment and in the end our EC2 machines kept crashing and we had no clue what was going on because we had poor standards :-)

    • @illicity2383
      @illicity2383 Před 7 měsíci +1

      @@barreltitor1419 Yup. Been there done that many many times in my career. Unfortunately its just the nature of the beast.

    • @davefunk135
      @davefunk135 Před 5 měsíci +3

      it is that. i commented above too and have struggled with this everywhere I've ever worked. Executives causing problems for everyone and then making you work overtime when you launch prematurely and the problems you told them would occur surface. Useless suits who add nothing of value to the org just making everyone's lives more complicated.

  • @RogerBarraud
    @RogerBarraud Před rokem +143

    80% of being a good programmer is knowing that you're a bad programmer.

  • @theondono
    @theondono Před rokem +17

    I like this format of posting the reaction later on YT because I can then make a more lasting comment having thought about it for some time.
    I think software has been under the same kind of process that modern manufacturing has.
    If you think about it, there’s a composition fallacy at play. For each single company, being nimble and quick to react, build fast and iterate, and to externalize non core functions to cloud services makes total sense.
    But in the big scheme, having all the companies in tech doing the same leaves you with fragile tech stacks full of holes, a patchwork of software built on shaky interfaces that become moving targets.
    Just imagine if we had in software something similar to what has happened in supply chains, imagine services randomly stopping, or being massively delayed, changing procedures,… it would be pure chaos.
    We’ve collectively leveraged our stability for speed, maybe we should consider reducing that leverage. Of course the catch 22 is that trying to do this unilaterally will bankrupt you…

  • @catsby9051
    @catsby9051 Před rokem +6

    The part you talk about at the 13 minute mark is definitely true... but in some ways that *is* the problem. Like, we have a lot more buggy software today because of the complexity. And often it is not immediately clear that the complexity actually is worth it.

  • @LagMasterSam
    @LagMasterSam Před rokem +32

    As far as complexity goes, Jon thinks the complexity itself is the main problem. His argument is that software developers have screwed up by making things needlessly complex.

    • @Mike.Garcia
      @Mike.Garcia Před 11 měsíci +13

      No everything is complex, I think his point is that developer's are willfully ignorant about lower level, fundamental computer science, software engineering knowledge.

    • @brandongregori995
      @brandongregori995 Před 10 měsíci +6

      Too much complexity to keep up with is definitely the main issue, but I don't believe software developers did that. Expectations have been raised and the range of devices has increased(and is still increasing).
      As far as developers needing to do better goes, they are working in abstractions most of the time where the fundamentals of computer science do not help. The problem lies in the fact that we iterate faster than ever, add more features than ever, and most of the time aren't even given the opportunity to write robust tests.

    • @thewiirocks
      @thewiirocks Před 9 měsíci

      @@brandongregori995software engineers didn’t drive the complexity, but we did fail to control it. Brooks talked about Accidental Complexity back in the 70s and how damaging it is to software. Yet we not only ignore this today, we go out of our way to run up the bill! ORMs, SPAs, MVC (ish) things, F***ing Spark, Python for serious projects, HIVE, on and on and on. I’m starting to feel like we’re dying under an avalanche of bad software driven by a realty-show level of popularity contest!
      This can’t end well.

  • @atla5_
    @atla5_ Před rokem +79

    Maybe the reason why we face so many bugs now is because we use software 24/7. What kind of software was 20 years ago average person would use? TV, radio, Christmas lights, static website with no code inside it?..

    • @ghosthunter0950
      @ghosthunter0950 Před rokem +8

      Isn't that part of the point? that we should be striving for simplicity.

    • @bobbobson6290
      @bobbobson6290 Před rokem +4

      20 years ago the software I used was
      games, more games, even more games, a ton lot more games.

    • @grawss
      @grawss Před rokem

      What about the games? Up until a certain point there were next to no game-breaking bugs in video games, and games like Pokemon were robust enough to have alternate programs built into them and they'll still run without crashing. Those old programmers knew how to power through bugs like nothing, but that was because they couldn't do patch updates. You can't update thermostat software without modern tech, nor coffee-maker software, and if you look at the crazy simple mechanisms being used back then, that stuff was built with exactly that in mind.

    • @bobbobson6290
      @bobbobson6290 Před rokem +8

      @@grawss no game-breaking bugs?
      You don't seem to have played on PC in the 90s...

    • @MGMan37
      @MGMan37 Před rokem +9

      @@grawss OG pokemon is pretty buggy. The fact that you are able to "have alternate programs built into them" is due to a bug resulting in arbitrary code execution, which would be considered a disastrous security flaw in software today.

  • @vitalyl1327
    @vitalyl1327 Před rokem +26

    I can sort of see where he's coming from. As a primarily hardware engineer, I do indeed feel this frustration - having all the cool formal verification tools in hardware and seeing software world being so reluctant to adopt even the most primitive forms of it makes one ponder about the future of the software engineering. Software engineering is so resistant to become, well, an actual engineering, where responsibility and safety is a key.

    • @alexanderlanz9712
      @alexanderlanz9712 Před rokem +4

      The problem is that most software has no reason to be "safe" and this makes a lot of software engineering different from hardware and physical engineering. Nothing bad happens when I need to reload netflix or close word. When software interacts with the physical world like in cars and planes it needs to be safe and then a lot of formal verification and testing happens.

    • @vitalyl1327
      @vitalyl1327 Před rokem +10

      @@alexanderlanz9712 The fun part here is that although safety requires an upfront investment, it cost less in a long run. Bad quality code piles up problems and explodes complexity until you cannot maintain it any more. High quality code causes much less problems in long run. Too bad code monkeys very rarely think long term.

    • @grawss
      @grawss Před rokem +6

      @@vitalyl1327 It's a lot easier to make up for lack of knowledge in software engineering. If a software engineer were to build a washing machine, it would weigh a couple thousand pounds, and have 20 tests for drum speed and zero tests for the electronics.

    • @JLK89
      @JLK89 Před 2 měsíci +2

      Systems complexity creep is a real problem. In the 60's, designing a new car/plane meant drawing a fuselage, sticking an engine in it, and adding a seat. Buttons controlled things through wires, not can bus or encrypted ethernet. Now it takes the military 40years to make a new plane, and car service technicians just shrug when they can't solve an electrical issue with a can-logger scan.

    • @zesky6654
      @zesky6654 Před 2 měsíci

      ​@vitalyl1327 it's not the programmers' fault, they don't make these decisions. Business is almost always the problem, they demand results in timeframed that don't allow for quality.

  • @m4rt_
    @m4rt_ Před rokem +3

    18:50 CZcams likes to call "Auto(1080p)" HD, but it often is lower quality, and often lags more than normal 1080p, so I have begun just always manually setting it to "1080p" because for some reason you can't set a default quality on desktop, but you can do that on mobile... but recently they have made even that bad. I know that they can add the feature to set a default resolution, but for some stupid reason they have decided to not do it, so I have to do it manually, and because of that it decides to sometimes not let me play the video, and even sometimes change the quality lower even when I have set it to 1080p, WHYY DO YOU HAVE TO MAKE IT SO HARD TO WATCH A VIDEO IN 1080p

  • @Hector-bj3ls
    @Hector-bj3ls Před rokem +4

    The point he's making about the face app is that it requires an entire Linux operating system (30Mloc+) to interface with the hardware while the ML bit is a few ~1kloc if that.

  • @aerialdude
    @aerialdude Před rokem +14

    I think Prime hit the nail on the head when he talked about how today we can just update things later, so we push out buggy stuff. So basically we are perpetually in a state of buggy software, because everyone all the time time is operating in this paradigm of "we can fix things later". Bugs do get fixed, but new ones come too, so we always are coping with bugs and now we have all grown so used to it that we just expect it.
    Also I want to point out that when Prime said "Do you really want people who write JavaScript to be controlling your house", I think he basically was admitting that this guy was right! The state of software is so bad you know you wouldn't want it controlling your house!

    • @atkascha
      @atkascha Před 7 měsíci

      Blow has some... off takes in general.
      He's very intelligent, but he is (was?) also a big Tesla / Elon / Carmack stan. Teslas have caught on fire, caused accidents, caused millions upon millions of dollars in damage, and people have been injured/died due to Tesla's software. Additionally, Elon has famously said that "fully autonomous driving is coming next year", every year, for the last 6 years. Should Tesla stop selling cars until the software is perfect? I don't think stock holders would like that, so there's a bit of the "Yuppie Nuremberg Defense" in there.
      And as you point out, game dev is massively different than other types of dev. Using Prime's work... Netflix is never off. Its not an application you download that has zero HTTP. Its running 24/7, with millions of people streaming from its servers at any given time. Blow has never worked on a product like that and has often bashed web dev of any kind.
      Another example is his "hobby?" programming language Jai. Its been in development, without a public release to this day, for 10 years. Not everyone has the infinite money glitch in order to work on 1 thing for a decade.
      HIs game Braid was neat though.

    • @user-kh7kx9en9l
      @user-kh7kx9en9l Před 5 měsíci +2

      @@atkascha Unfortunately a lot of coders are bootlickers to the tech industry. One of the worst things about this industry.

  • @Mike.Garcia
    @Mike.Garcia Před 11 měsíci +1

    11:52 30 years ago DOS applications were shipped with a myriad of disparate hardware drivers, and the application had to work with all combinations

  • @ruslansmirnov9006
    @ruslansmirnov9006 Před 5 měsíci +1

    20:00 i remember seeing a HUGE lcd screen on top of a 35 store building in Moscow back in 2010 stating `undefined` in 6-meter tall letters for DAYS...

  • @andythedishwasher1117
    @andythedishwasher1117 Před rokem +8

    You do have a very valid point about the comfort layer introduced by modern CI/CD pipelines and other rapid re-deployment strategies. When you can ship a patch with a quick CLI command, you're not sweating very hard when you hit commit.

  • @theelectricprince8231
    @theelectricprince8231 Před rokem +6

    3:37 , he has a point. I have observed this in gaming, new games are only different because of the advances in hardware. That's why the gap between gaming generations is so small now. I look at a lot of new releases and I don't see why these couldn't be on a PS4 or even a PS3.

  • @soggy_dev
    @soggy_dev Před rokem +56

    I dunno why, but I never thought I'd see a Prime/Blow crossover 😄 My two favorite software opinion guys hahaha

  • @kiaranr
    @kiaranr Před 7 měsíci +2

    I'm a software engineer at Epic Games. I use about 25 peices of software on a daily basis. It's just a constant battle of workarounds, restarts, hacks and tears. It legit stresses me out.
    Even moreso when I see these issues in my OWN software.
    I felt this talk on a deep, personal level.

  • @funguy2627
    @funguy2627 Před rokem +18

    all the updates ive seen in apps made the product more bloated, and unreliable. I find that I hate doing updates because I kind of expect some kind of behaviour I don't want. Big corp keep shoving new features with more bugs and then they force on the user to update it. Apps just keep on changing, the dev team prob keeps changing im not surprised why people expect software to be crap with issues

  • @irlshrek
    @irlshrek Před rokem +23

    the reason I like rust so much is because being able to limit errors to (mostly) logic errors..is huge. I mean something happening and having no idea why is the shit that keeps me up at night

    • @NathanHedglin
      @NathanHedglin Před rokem +4

      Yeah. The reason why I'm looking more into ML languages and proof languages like Coq and Agda.

  • @ChrisPatti
    @ChrisPatti Před rokem +80

    you totally nailed this. Jon Blow is an incredibly smart guy with an incredibly specific viewpoint derived from very specific experience in the game development industry. I work in platform engineering or DevOps as the olds used to refer to it :-) I mostly use Python, because the truth is it really sincerely doesn’t matter how fast my code is when it will spend 99.999% if it’s time waiting for an upstream API return anyway.

    • @ongeri
      @ongeri Před rokem +12

      What of that upstream api? Your code may also be upstream to something else you know, and sometimes it is a complicated web where one slow element may cause the entire system to appear sluggish, a kind of cascading failure. So that 0.001% of the time matters a lot.

    • @logananders7334
      @logananders7334 Před rokem

      Hey Christopher, I wouldn't mind asking you some stuff about your job. Could we talk via dm?

    • @HobokerDev
      @HobokerDev Před rokem +2

      Latencies add up. Fast.

    • @gogudelagaze1585
      @gogudelagaze1585 Před rokem +2

      @@ongeri It really doesn't matter, because IO latency makes the bulk of the waiting time. We're talking different orders of magnitude.

  • @attilazimler1614
    @attilazimler1614 Před 5 měsíci +1

    Yes, with we can ship bugfixes at the moment notice, unfortunately every such fix delivers two additional bugs too.

  • @allan4386
    @allan4386 Před rokem +10

    I think he means the quality of MOST of the applications made using whatever new s/w languages hasn't improved, on average... they've been using the improvements in hardware as a crutch.

    • @prestonrasmussen1758
      @prestonrasmussen1758 Před rokem +2

      But the issue is that's just not true in an apples to apples comparison. Websites have functionality now that was unimaginable 30 years ago

  • @carlynghrafnsson4221
    @carlynghrafnsson4221 Před rokem +3

    I remember my Borland Visual Turbo C++ w Protogen RAD tool. I think over time, the only RAD tools now are mostly GUI. So, I see spots missing... like RAD tools for researchers. Scientists want app dev, but they could never afford that or find time to learn. I see that as an opportunity for RAD. A statistical package PLUS a fun plug'n'play compile, distributed service access. But generally, I see the future of AI in executive management suites that not only collect data, but help bossman make a decision or automate... taking out entire floors of accountants. Stuff like that.

  • @MegaMurcelago
    @MegaMurcelago Před rokem +4

    One thing about more tolerant behavior toward broken code is coming from faster hardware, as it is also said in the beginning. Just imagine it 20 years ago - you are starting a program that takes 1 minute to load a file, if the program crashes after some changes in the file, even if the file is updated correctly, that said the program is now on the verge of being deleted if there are some alternatives. On the other hand - you can now just restart thread/hole process and you will have a working piece of code after crash in a second or two.

  • @benjamin_fdw
    @benjamin_fdw Před rokem +2

    I was watching at my friend tuning is car AC on his touch screen and I was impressed how long it takes, I mean, I used to the good old switch that takes about 0.1s

  • @ex0stasis72
    @ex0stasis72 Před rokem +4

    As a gamer who plays mostly western games, and not used to Japanese game jank (as opposed to whatever jank we in the west have gotten used to and done see), I had started playing FFXIV seriously after several failed attempts, but this time, I was making a list immediately after every frustrating thing in the UX I experienced.
    I ended up with a list of hundreds of tiny little issues that, if I complained about any one thing, I'd probably get laughed out of the room for being petty.
    So I patiently kept gathering a huge list of issues over months, as I grew to love the game more and more.
    When I look back on the list of issues, those issues still bug me, but I no longer notice them anymore because I've often found workarounds or just developed a muscle memory for how the game devs intended players to use the systems. But once I had a large enough list, and I wasn't hardly adding to it anymore.
    I combed through the list and removed about a dozen issues that I had that had since been resolved with updates, and then I posted it on the forums.
    It was such a long list that I had to copy and paste it into 4 separate posts to get around the characters limit.

  • @funkstication
    @funkstication Před 5 měsíci +1

    19:01 Most replayed. "Was that my notification or was it on the video?" 🤣

  • @abyzzwalker
    @abyzzwalker Před rokem

    Fantastic video and analysis.

  • @Zaf9670
    @Zaf9670 Před 9 měsíci +2

    The fact that the middle finger ended up being the "we accept it" at the end may not have been planned but... it was definitely destined.

  • @Exilum
    @Exilum Před 7 měsíci +10

    The thing is, I'd tend to say I have the opposite observation of what he encountered.
    There used to be a time when software having issues was way more grave than today, and it wasn't as rare as we like to remember things.
    Every issue he had couldn't be said to be anything more than small annoyances. The biggest one was a form that he had to refill.
    Even just taking 2010, I still remember when having software crash in windows 7 had a non-negligible chance of blue screening windows itself. There was also these times when one device's drivers breaking could break all devices. What about when you started a game and it crashed right away because it needed a specific dx version? What about these innumerable softwares that could just break if they crashed at the wrong timing?
    It's basically the same as what he did, if you look back at your daily life then, you had a lot of troubles too, but their effects weren't dampened by the layers of abstractions, so these sure were very fast and powerful problems.

  • @lucianmot3999
    @lucianmot3999 Před rokem

    Please make more of these. This is great.

  • @just_ppe
    @just_ppe Před rokem +3

    I suggest watching the full, original presentation, especially the part about trivia knowledge and adding fake complexity to the software.
    A great example are all those module systems for js, webbundlers and metaframeworks bs...

  • @irishskier9432
    @irishskier9432 Před rokem +5

    This guy clearly has not worked in enterprise for a long time, so many wild assumptions in all of these takes. This is the software equivalent of your maths teacher telling you not to use a calculator for basic functions. Using tools that improve speed of development and abstraction are not necessarily a bad thing. Any decent dev worth their salt understands the underlying fundamentals. Those who don't get found out pretty quickly once the ask becomes more complex and requires fundamental understanding. The entire thing is essentially a luddite argument.
    The idea that software relies too much on hardware, what's the solution then? Go down to lower levels and redesign a whole language to meet a specific use case? This completely defeats the purpose of iteration and OS principals. Software has always scaled with the resources available to it. People who care about these real fine grain issues about resource usage are weird to me. Who do you want in your company? The dev who spends 6 months improving a set of functions to improve performance, or the dev who pushes out an entire feature to the client and delivers on the ask and fulfils the requirements. The reality is the client doesn't care about the extra 1 percent performance, they care about being able to run their processes 6 months earlier and then run them continuously. That's the whole point of iterative development, the client comes back for a performance increase down the line and we charge them for that too.
    If you are good at something never do it for free. I know this take will piss a lot of people off but that's the reality of real world development. The percentage of Devs who care about the academic perfection checklist of reducing completion time of an algo, or reducing all bugs to zero is a vanishingly small proportion. If the ask is for 80 percent code coverage. guess what you are getting? exactly 80 percent and not 1 percent more.
    Most Devs care about doing the minimum to fulfil the ask this is just the reality of the real world of work outside academic institutions. It may be a "room temperature IQ" take as you put it but the reality is deliver the ask or get sacked, upper level management simply does not care that you resolved a weird bug that only you know about or that you improved performance on a backend process function. Unless it was specifically related to a client ask. Ignoring this aspect is either an oversight or a willfully misleading take. Its all well and good when your primary income is from you tube and not from actual real world development, but when you're under time pressure from a client and management the things you think are important are "nice to haves" and nothing more. No one is going to redesign an entire JS framework because "you think its flaky". It may have been an acceptable outlook 20 years ago when all the internet companies were start-ups ran by engineers. However the reality is, the business people with no programming knowledge took over the upper management in all these companies years ago. The era of perfection that used to exist, with each new version being a self contained work of bug free art are gone. Iteration and rapid CI/CD are the new name of the game and its not going to change because some people have high minded ideas about what "software should be".

  • @shampoable
    @shampoable Před 4 měsíci +1

    19:00 protip - if it says 1080p auto, it's not 1080p. Need to force it, otherwise youtube doesn't want to burn their servers

  • @simonrenblad490
    @simonrenblad490 Před rokem +9

    Funny that he starts with the 737MAX example, because it most definitely had problems other than software. The whole reason they needed a software fix in the first place is because the aerodynamics of the plane made no sense. Not to mention the fact that the software had to rely on like a single sensor, or that the pilots were given minimal training on the new behavior of the plane. Safe to say there were more problems than "only software".

    • @JosephSalmans
      @JosephSalmans Před 4 měsíci

      I totally agree with this. It went way further than just bad software. Are we even sure the software was bad? Seems like no redundancy of the hardware was the problem.

    • @JayXdbX
      @JayXdbX Před 4 měsíci +1

      I'm fairly sure the 737MAX relied on 2 sensors which had to be in sync. The crashes or at least 1 of the crashes was caused by the sensors giving different results which caused the computer to go haywire. also the sensors being out of sync could happen by simply replacing only one of the sensors.

  • @dagadbm
    @dagadbm Před rokem +3

    move fast break things.
    thats why :)

  • @kaanbargeld
    @kaanbargeld Před rokem +7

    Reopen the software if there is an error. Personally, I don't even fully understand how the radio works and I write some gibberish in the ide and it becomes a website! It's amazing enough for me.

  • @kriskoss1325
    @kriskoss1325 Před 9 měsíci

    I really, really enjoy your channel !

  • @todo9633
    @todo9633 Před 3 měsíci +3

    "Why do they keep recommending me my own video?"
    Cause real recognize real.

  • @aes0p895
    @aes0p895 Před 6 měsíci +2

    NASA would never knowingly 'ship' a bad product (launch), regardless of how complex it is, because failure is unacceptable. It's the same with software; if customers theoretically would never buy subpar software, the standards would go up immediately. But people just keep buying TVs and microwaves and all the other things no matter what.

  • @btbcomputing2500
    @btbcomputing2500 Před 7 měsíci +1

    Let me expound on what Prime said about the surface area expanding, because it not doubt has. It used to be that all software was written for a specific target, you had a limited set of shared libraries (possibly just the OS or maybe none at all) and mostly used static libraries or what you wrote yourself. Everyone running your code would be running it on the exact same hardware setup, and any time a bug happened due to a weird hardware setup people could mostly get back to what was needed. Today software is no longer written for the specific (except maybe game consoles and hardware applications, though companies will avoid being specific if they can so they only have to write it once), it is written for the generic. There are almost infinite number of targets out there (at least millions of different configurations) and you have to try to write something that can run on all of them bug free. Any tiny bug or unexpected behavior from any Service, Library, Driver, Operating System, Browser, piece of hardware and all the ways these interact, any dependency, can absolutely wreck your code and introduce bugs that never existed on the system the code was written on. This, I think, can lead to the mentality, and truth in the generic, that bugs are just going to happen. You can't account for every edge case when you can't predict every setup someone will try to use!

  • @mito._
    @mito._ Před 3 měsíci +1

    3:42 - It's exactly like modern VGX and CGI. Good visuals are riding on the backs of better hardware and software, but the case remains limited wholly by the talent of the artist behind it. Such remains true in the case of software engineers vs quality.

  • @lesto12321
    @lesto12321 Před rokem

    about heater in software: non connected smart valves for living room and bedroom. I heat them up only when needed.

  • @SoapSoapCrayon
    @SoapSoapCrayon Před 3 měsíci +1

    It's funny to me. A game like Vampire Survivors was written in JavaScript. Won game of the year, it's a very complex piece of software, games are some of the most complex things there are. The thing was like 5mb total at launch. Less than most webpages these days.

  • @bwhit7919
    @bwhit7919 Před měsícem +1

    I wonder how much of this comes from the Silicon Valley startup advice: “build fast and iterate.” Startups are told that they shouldn’t polish their product until they know they have product market fit. Which leads to broken demos, which leads to broken MVPs, which leads to broken products.

  • @Max-bh8tg
    @Max-bh8tg Před rokem +7

    You should react to "The Thirty Million Line Problem", it's related to this.

  • @yoshiyahoo1552
    @yoshiyahoo1552 Před rokem +3

    For me personally I think the bugs and annoyances don’t stop me from getting my work done and that I just have to push through those troubles to get something finished. If the bugs stopped my work or stopped my from playing then Id have a justification to complain, but if it can still do it’s basic things then I just have to push through and get stuff done.

  • @hannessteffenhagen61
    @hannessteffenhagen61 Před rokem +2

    If people are talking about "back in the day, when software was less buggy" I really have to wonder what time they're referring to. It must be more than 30 years at least, because certainly most software from the 90s I used at the time (and had the privilege to experience again later in life when working with systems that were still being used for some godforsaken reason) was just as broken as shit we have today - or, I should say, significantly more broken, because it just didn't serve many use cases that the creators hadn't envisioned (such as the user not being an english speaking US american in 1994).
    I certainly agree that software development practices have not kept up with the increasing complexity of software, and we have much more accidental complexity nowadays (way too much unnecessary compartmentalisation into things like microservices with little justification besides "that's the big guys are doing, it's probably a good idea for our product with like 200 simultaneous users"), but we also produce _shitloads_ more software than we used to in the past, across a much wider variety of hardware configurations (yes, yes, most consumer hardware is running some variant of x86 or arm these days, but it's not like that's the only thing you need to take into consideration) to wider audiences. Of course it doesn't _help_ that there's basically no notion of due diligence in this field and we have a ton of people joining through 3 month bootcamps, but I don't think that's the main cause of our issues.

  • @scvnthorpe__
    @scvnthorpe__ Před rokem +2

    To be honest one of the best things we can do for software quality is TDD; I don't want to have to step through a debugger (which at that point is just spicy manual testing) and really dumb and elusive bugs that ask of me to do so tend to just proliferate as a result of either tight coupling, poor management of mutable state or both.
    But again, these are all things that are selected against when thinking "for this project, how will I make sure I can test all these bits?"
    I remember spending about a week when I was first training to code thinking "how the hell am I going to mock all these dependencies??", but then it all just kind of clicked.
    It's also thanks to TDD that I discovered where I prefer to go for straight functional or even procedural code vs an over-engineered singleton.
    The best thing period that you can do is also not make your programmers do crunch - and not even as an 'oh it's voluntary but yaknow wink wink nudge nudge' thing, I mean don't even think about crunch unless you're in a literal emergency - but to be honest you, once again, should think about testability as soon as possible to avoid a brewing shitstorm.

    • @dirtydan8044
      @dirtydan8044 Před rokem +4

      Tdd is not the answer to the inherent problems of writing good code.
      The only thing people care is that it works, no matter how tf it was built.

  • @codeman99-dev
    @codeman99-dev Před rokem +22

    One more factor: A general understanding of how software is made.
    The percentage of people who understand software over time is definitely on the rise.

    • @NatSPlay
      @NatSPlay Před rokem +21

      More people having general understanding also means that there is more misunderstanding ironically

    • @KilgoreTroutAsf
      @KilgoreTroutAsf Před rokem

      A quick shoutout to all those hobbyist bridge and airplane engineers out there.

    • @kti5682
      @kti5682 Před 7 měsíci +2

      ​@@KilgoreTroutAsfWhat I miss in this discussion is that run of the mill software never receives the scrutiny the airplane software receives. I mean just look at 61508-3 normal software skimps out of easily all of the requirements for functional safety.

  • @L1Q
    @L1Q Před rokem

    20:20 yes, their UI is made using Panorama engine, which is heavily modified CEF

  • @jesusjar11
    @jesusjar11 Před rokem

    16:06 instant flashback of my copy of Sims 2 Pets fro the GBA that had a bug in a mainstory mission which made it impossible to continue

  • @nomoredarts8918
    @nomoredarts8918 Před rokem +31

    He convinced my employer, I have no job now

  • @miletech
    @miletech Před rokem +1

    9:00 You are wrong and that is a bad take. You know what's better than a physical switch or remote control for your your air? Laying in bed without your glasses too drunk to see or walk and saying "Alexa, make the air colder", and fall instantly back asleep snoring. You don't even need to open your eyes. Smart home stuff is boss af.

  • @sakuyarules
    @sakuyarules Před rokem +1

    Agree with his main point, but I kinda feel like there's something up with his computer if he has all those problems back to back to back; maybe it's operating system/software interoperability issues?

  • @mobugs
    @mobugs Před 5 měsíci +1

    I think Jblow forgets how often software would fail in, say, the 90s. there was a lot of improvement since followed by an explosion in digitizing and fast shipping everything coming that came with a decline in quality tho.

  • @L1Q
    @L1Q Před rokem

    whait, how does YT progress bar goes OVER half of your microphone arm?
    half way through I realized it's just wrapped in green tape, black on black makes it trippy like that

  • @KangoV
    @KangoV Před 3 měsíci

    I'm using software that was originally written on an IBM System/36. These systems were design to have all the symbols compiled into the program objects so when they were moved to newer machines (System/38, AS/400, System i etc), the operating systems could recompile these objects for the newer machines. These apps now take advantage of the newer machines. No code changes are required. PCs are so behind.

  • @billgrant7262
    @billgrant7262 Před rokem +1

    28:21 this is literally the same as the companies are greedy point so that makes you a room temp IQ

  • @FatherPhi
    @FatherPhi Před rokem

    Damn I love this content

  • @Alkis05
    @Alkis05 Před 6 měsíci

    When I am buying a bus ticket in my country, the website for the bus company is horrible and full of bugs. One of the problems is that when its getting your credit card data, it asks for your full name, but they probably didn't change some default settings and it is limited to 20 chars, which is not much for names in romance language names (we usually have 3 names). So I can't pay the ticket, unless I go into the source code of the page and increase the limit manually. Luckly the underlying buffer doesn't overflow with my name, but I wonder how it handles bigger name.
    By the way, I still have to pay a convenience fee for the inconvenience of working around their shitty website.

  • @alangamer50
    @alangamer50 Před 6 měsíci +1

    I think this originates from the "minimum viable product" concept of just making it work, and fixing it later, because fixing bugs makes no one money, delivering new features does, so the bugs just keep accumulating and getting buried in millions of lines of code beyond any one person's comprehension

  • @10e999
    @10e999 Před rokem +1

    hi prime. May I suggest putting the source of the reacted videos in your description?
    I like your stuff. Take care.

  • @SimGunther
    @SimGunther Před rokem +5

    JBlow is one of the most dogmatic Elon Musk fanboys I've ever seen. Doesn't mean his views on software are invalid.
    It just means he might only look at one side of the equation (delivery/gas price ~= dynamic languages and bad engineering education - short term inflation) when he also needs to look at the other side of the equation (lack of good processes to keep up ample supply/storage of available materials & goods without globalization ~= outdated von Neumann architecture, hyper-hustle/capitalist culture working everyone to the bone for a minuscule raise, and acceptance to give up "personal" computing to appease normies - longer term inflation) which we haven't analysed properly since the Oil Crisis of 1973.

  • @ilnon1
    @ilnon1 Před rokem +1

    Yoo your voice reminds me of Steve Carell but most notably him playin Gru Despicable Me. Very interesting. Subbed.

  • @spross216
    @spross216 Před rokem +1

    I am a SOC operator for a software company, and have to frequently page engineers and host outage calls when their software breaks. There are too many “moving parts” that can break outside of the companies sphere of influence. It might be a bad update to a 3rd party api that the software leverages for a certain feature so they didn’t have to reinvent the wheel etc. Maybe the only solution to that problem, is to pencil in some of those “must have features” as luxury items that aren’t necessary and just go back to basics? I don’t know 🤷🏼‍♂️ I’m not big brainded enough to figure that one out. I’ll leave that to the 50 lb fat heads

  • @drizztduncan4971
    @drizztduncan4971 Před rokem +2

    I guess it’s just capital moving faster and faster which leads to business getting as fast as possible which leads to MVP to cash out and lower the pressure, and in order to lower the capital pressure we have early access and pre-order🎉🎉.

  • @jinyeom766
    @jinyeom766 Před rokem +1

    MCTS + neural net approaches existed for a long time, I think he's not exactly wrong about AlphaGo being MCTS + neural net (+ advanced hardwares)

  • @aenguswright7336
    @aenguswright7336 Před 3 měsíci

    The other thing is that some of the things we have to live with today are the results of shortcuts in the “glorious” past. There is stuff in the basic web protocols which is objectively bad, and it’s got layers of layers of patches and added features which bloat everything and make it fragile because they didn’t design it right in the first place, and it can’t be changed now. It’s the same with text, albeit Unicode is slowly making it better.
    We could fix a lot of js problems tomorrow if we just added a feature flag which enabled more modern syntax (like use-strict).

  • @sjbarras
    @sjbarras Před 6 měsíci

    The wikipedia page for (ml) reinforcement learning was created in 2002 and cited a 1996 book

  • @ExpertOfNil
    @ExpertOfNil Před rokem +6

    A lot of stuff to consider here. Seems like some confirmation bias at play though. Also, willingness to ship software with bugs seems like a product of customers being unwilling to wait for something refined.

    • @ea_naseer
      @ea_naseer Před rokem

      ship software with bugs... have you met the gaming industry?

  • @aidankieffer
    @aidankieffer Před rokem

    You do want software for hvac and building systems for reporting and automation. The problem is connecting all these systems together. It’s a big servicing and integration problem for installers right now.A friend of mine hopes to setup an open source company for this, with network security as a focus

  • @galenseilis5971
    @galenseilis5971 Před 5 měsíci

    In regards to machine learning, I think that there have been advancements in algorithms. However it is also true that some of the mathematics of machine learning models (including backprop) are older than some people seem to realize. There's new stuf, and there's old stuff. There is also integration of old things that have not been integrated, such as geometric deep learning or graph neural networks. There's no particular reason why these could not have been conceived of many decades before they actually were, but here we are.

  • @robrick9361
    @robrick9361 Před 9 měsíci +2

    18:04 There's actually a language that allows you to do that, it's called C++............😜😜😜😜

  • @microcolonel
    @microcolonel Před rokem

    Watch the WHOLE talk man. It's great.

  • @dannyhunn6025
    @dannyhunn6025 Před rokem +1

    We are no longer creating small purpose build application that do one thing really well, Unix piping from one to the next would be a good example. A bunch of small chained together isn't how we develop things anymore or process things anymore. Even simple software today is largely more complex and less modular then ever before. On top of that we are using things from a developer that we have never met and when he makes changes it may just break everything, we cant just walk down the hall and talk to Bob anymore.
    We are able to be more flexible so at time we abuse it.
    Developers to day can come from all walks of life they don't need a Computer Science, Computer Engineering, ect. Yet we still rely on people that may not have a solid understanding of the fundamentals by using their libraries. One good example is the ability to decrypt a Man page or they may not even understand that something like that exits. It could have been hacked together with CZcams videos.
    The landscape is more Complex, we are using libraries from people that we don't know we can trust or would have any accountability, and rather then make a bunch of highly refined small things that are interlaced together to create a cohesive whole, we build it bigger and more complex.

  • @RemotHuman
    @RemotHuman Před rokem

    Netflix on my old computer will not stream in HD. It starts out HD if you reload the page but it always takes 2 minutes to become bad quality, even though I turned on always use hd in the settings. I used to start a show on Netflix and get tired of the reloading and then switch to an illegal site. Honestly I'm not even sure I've tried Netflix on my new computer, there's been nothing good on for a while.

  • @geneanthony3421
    @geneanthony3421 Před 4 měsíci

    I'm guessing a lot of the issues are outsourcing for cheap labor and unrealistic expectations in order for managers to peacock. Not sure if it's the reason, but seen it in pretty much everywhere else.

  • @cogno-marco3724
    @cogno-marco3724 Před rokem

    i'd like to see the reaction to the full video (preventing the collapse of civilization), is it somewhere?

  • @roganjosh6220
    @roganjosh6220 Před 7 měsíci +1

    regarding the point about having services to contend with nowadays, the rest of this talk literally exposes this

  • @mario7501
    @mario7501 Před rokem +3

    Wait until no-code increases in adoption and fixing a bug devolves from making your own engineer open the text editor to get the bug fixed to calling support of the company developing the no code tool and waiting for 12 months until you get a reply from an actual human who knows anything about the technology, because the no code tool company has customers that make them more revenue.
    It's already a problem with the cloud in general. I still have an open ticket at Azure from a year ago where I wanted them to increase the quota for a service from ZERO to anything that is non-zero, so I could use it for a PoC.
    Every month I get an email letting me know that there is still no approval for the quota increase. And this is on my corporate account, the company I work for is a Microsoft partner and brings in millions in revenue each year for Microsoft and was perfectly happy to pay for that quota increase a year ago.

  • @ea_naseer
    @ea_naseer Před rokem +3

    10:05 disagree. If software has a quirk, users would find a way to bypass it. This has been true since the dawn of software.

  • @styleisaweapon
    @styleisaweapon Před 4 měsíci

    Its because most everything is a bodge now, and you arent supposed to know which stuff is bodged, because "implementation details" ... quick question: how many different audio buffers are between your web browser and your headphones? do you have any idea at all? can you even make a reasonable guess? would you be surprised if it was more than 6? (it definitely is) ...

  • @RPGabe
    @RPGabe Před 5 měsíci +9

    Ah yes, the good old days when software famously had zero bugs and people had endless patience for perfect expensive software to ship for their standardized offline devices.

    • @remsee1608
      @remsee1608 Před 3 měsíci +2

      That’s exactly what gaming was from the 90s until the mid 2010s