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.
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.
@@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. :^)
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.
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.
tbh a lot of bank code is pretty horrible too, legacy or not. his perspective is quite narrow as it has always been pretty bad, I'd argue due to short profit cycles. it's right in the core of how we operate unfortunately
A lot of bank code is bad. I also disagree with his 'legacy code was good' take. No. Not really. Secondly, Adobe, Google Gmail, Smart Home systems, VSC aren't 'fart' apps, I think that's exactly why he exclusively chose those examples
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 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.
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
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).
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
@@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.
@@u-5-v9i 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.
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.
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.
@@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.
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.
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.
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.
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).
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.
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 :-)
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.
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.
@@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.
@@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.
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.
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.
@@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.
@@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.
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 ).
If engine does 99% of job, game programmer doesn't need to much worry about code optimization. In reality performance issues in games are very often caused by non optimized assets, while code is ok.
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.
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.
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.
@@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
@@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.
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?..
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.
@@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.
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
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.
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.
Uh, back in 80s we got IBM PC, Apple II, TRS-80 CoCo, Atari ST, Macintosh, Amiga, Apple IIgs, Commodore 64... That was solved back then using bytecode interpreter or painfully port software to different platforms. Often every hardware got own software that didn't exists on other hardware.
@@neruneri Root cause of the problem is that business idea of technology companies is to spread own proprietary technology to general use and take royalties. Starting from CPU instruction set. Avoiding that requires to make competitive option. I don't mind that we got competition but standardization actually works well when things are simple, like character set or CPU instruction set. Software developer should have hardware abstracted away completely or as much as possible. Exception is working on embedded scene or something where software and hardware together make product and development is optimizing watts/price down. For most of the software it should be usually problem of that platform provider to optimize how to make that abstracted software run efficiently while software developer is targetting to browser/container.
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.
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.
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.
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…
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.
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.
@@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.
@@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.
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.
@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.
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
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.
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!
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.
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
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.
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.
No everything is complex, I think his point is that developer's are willfully ignorant about lower level, fundamental computer science, software engineering knowledge.
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.
@@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.
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.
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".
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.
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.
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.
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.
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.
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.
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.
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.
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".
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.
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.
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.
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.
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...
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.
18:50 TH-cam 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
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!
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
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.
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.
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.
I think this whole talk can be boiled down to a classic “the grass was greener back in the day” thing. I don’t know who that guy is, but at one point yt algorithm started spamming me with his videos and I watched one, where he shares his opinion about oop vs functional and it was complete bs. It was just a lot of populist well-arranged metaphors that on a surface level sounds logical but when you think about it deeper don’t stand any criticism, I see exactly this pattern repeating here.
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.
I don't feel like software's quality is inherently driven by hardware capabilities. 20 and 30 years ago, software was written proportionally to the capabilities of hardware, but was buggy as hell. Mainly because of the lack of proper testing tools, and established standards that now prevent us from writing carastrophically bad code. In that time, if something crashed in a program, it crashed your OS, and yet the software was proportionally smaller, so it ideally should be easier to debug and secure, yet, it wasn't.
John Blow has a lot of confirmation bias. What about all the times software works seamlessly? That’s way harder to notice. It’s easy to notice when things go wrong. The fact that John Blow felt compelled to make this talk is indicative of the fact that software has gotten really magically good. Because of this, our standards have risen and we are more sensitive to even the smallest software failures. If most software was failing then we wouldn’t be able to notice the failures because there would not be enough successes to contrast them against. Failure can only be noticed amidst a plentiful background of successes, which is what the software landscape is today in actuality.
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.
I actually get nervous where there ISN'T a day 1 patch for games these days. You know the game needs it, but it isn't ready yet so will be rushed so you're really looking at a "day 2" patch before it's actually playable.
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.
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.
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
I think the issue is that software getting more and more complex because we want it to do more and more things and we want it to be able to evolve over time. This complexity requires more abstraction and standards that lead to a lot of boiler plate. A lot of people don't like OOP because of this. However, complex, scalable software requires teams of people to manage. These teams need the abstraction to have any hope of managing and scaling the software.
The simplicity of the past was due to lack of power in hardware at that time, which was a useful constraint that can still be utilized to this day. Now, it's replaced by "I want all the features because hardware's powerful enough, right???"
Software complexity does not match the functionality complexity most of the time. Pretty much every single bit of software you can name can be implemented orders of magnitude simpler without losing a single bit of functionality.
"A lot of people don't like OOP because of this. However, complex, scalable software requires teams of people to manage". I wonder how the Linux kernel does it, since it doesn't do OOP. How in the world does it manage complexity without OOP? In fact, how did the universe even manage to exist before OOP? I guess we'll never know.
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.
Notice how most of his examples were proprietary/private code solutions. Bcse some, if not most, of this business are not software makers, they are money makers. They dont care if their software is actually the best it can be, they care if it gives them money. Even if the programers are the best there are, most of the time they dont have the best conditions to develop properly. But it's not because is proprietary, is because on who is their target audience: common people. Developers understand what is bad software, they understand what can be better, thats why so much developers prefer open source since we can actually see, judge and even change/fix the code, but for common people this is all magic and they cant differentiate what is simple and what is impossible, so they use whatever is sold to them. The target audience of this software is people who arent that critical and/or dont understand software enought to find alternatives that work better, so there isnt a loss of money for the business and finally there isnt any motive to become better
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🎉🎉.
The Android TH-cam app that I'm using to watch this video bugs about 10 times per day, freezes for more than 10 sec 2-3 times per day, crashes about once per day, and crashes the entire phone about once every two weeks or so. And all I ever use it for is watching videos, and reading/writing comments. In other words, the most basic TH-cam functionality.
The blame is in the commidification of software development by business leaders. Businesses allow technical debt to build up with a "if it aint broke dont fix it" attitude to extract as much revenue from an otherwise subpar product. Meta didnt want to scrap their shit php code so they went so far as to build a fucking homebrew php to c++ compiler and keep their codebase in php. The result is a patchwork user experience where the transition between different technologies, as a user, is like driving over a road paved in different materials with different textures and colors.
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
Opening task manager and ending your task was a completely normal and expected user task in Windows more than 20 years ago. So I find this a poor argument for software being on decline. More people user more software daily than ever. I’d argue that software today is more resilent and fails less than ever before when you weight how much people use it compared to before. Fails per cpu instructions has probably gone way down. I think people have to be mindful of cognitive bias here.
The base layer of software is economics, but our economic system is actually ponzinomics. You see this degradation of quality everywhere. Remember when Chipotle was not disgusting? Eventually a ponzi runs out of steam and I think that is really what we are witnessing.
He also completely missed the point that today most businesses don't even know what they want with companies the next day, let alone years ahead... Most customers expect CHANGES at same day speeds, because it's just easier to "try it in prod", then planning and figuring it out.
Blame MVP and Agile not us, most of my time is spent arguing with MBA project managers suits, how *this* doesn't make sense and if we do it this way instead of taking the time it can introduce a bug where if a user moves to 24 then 22 then 20 it would ring the phone, "we will fix that in the future, I need to show the client and make money now, what is the odds of that happening?" I simply gave up I don't want to argue with my clients all the time it's exhausting.
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 TH-cam 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.
"The layers of abstractions and problems have greatly grown in comparison to 30 years ago" -- exactly, but there are the problems related to the actual problem (transforming data_x into output_y), those problems that are necessary and unavoidable, and there are those unnecessary problems, not required by the actual problem, that have been created by many things, not the least of which is the added/unnecessary abstraction (which isn't the same thing as saying that all abstraction is unnecessary). Where I've seen many disagree with Blow is in defining which abstractions are necessary and which aren't. Saying software is slow because of all these new problems and abstractions and black-box libraries, etc... is actually to agree with Blow. The question then is "what to do about it?"
"Do you really want people who write JavaScript to be controlling your house" made me laugh harder than it should
It literally encapsulates the talk though
@@NatSPlay good pun.... It threw me for a loop
DIES IN NODERED
OR the flight control software for the airplne you're on.
@@kurtnelle spacex used chromium for their rocket controls inside the dragon capsile
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.
totally agree
"Processing power is cheap" 🥲
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.
@@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. :^)
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.
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.
tbh a lot of bank code is pretty horrible too, legacy or not. his perspective is quite narrow as it has always been pretty bad, I'd argue due to short profit cycles. it's right in the core of how we operate unfortunately
A lot of bank code is bad. I also disagree with his 'legacy code was good' take. No. Not really.
Secondly, Adobe, Google Gmail, Smart Home systems, VSC aren't 'fart' apps, I think that's exactly why he exclusively chose those examples
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…
BSOD used to happen weekly. Now it's once or twice a year, if not less.
@@NostraDavid2 exactly
@@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.
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
@@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.
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).
Jesus Christ said, that there should actually be a free lunch.
Half baked software is everywhere and it's a welcome surprise when it works as intended.
agreed
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
@@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.
Even on sites like TH-cam and Facebook there's obvious, unfixed bugs.
@@u-5-v9i 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.
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.
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.
Not to mention that Jon says in his talk that GMail makes the same mistakes that Microsoft Word did in the 90s and 2000s
@@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.
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.
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.
Y Combinator always recommends to ship your Minimal Viable Product as fast as possible even if half broken.
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.
"Do you really want people who are writing Javascript to control your house?" Instantly liked lmao
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).
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.
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 :-)
@@barreltitor1419 Yup. Been there done that many many times in my career. Unfortunately its just the nature of the beast.
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.
I would say "Jaded" tbh
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.
Smart people are angry because they see all the stupid shit.
@@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.
@@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.
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.
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.
@@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.
@@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.
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 ).
If engine does 99% of job, game programmer doesn't need to much worry about code optimization.
In reality performance issues in games are very often caused by non optimized assets, while code is ok.
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.
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.
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.
@@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
@@saniel2748 Imagine if photoshop only load the features that the user sees on the screen at start
@@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.
@@officiallyaninja Adobe, a multi billion dollar compay can't afford to improve load times. Yeah, no one is going to buy that.
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?..
Isn't that part of the point? that we should be striving for simplicity.
20 years ago the software I used was
games, more games, even more games, a ton lot more games.
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.
@@grawss no game-breaking bugs?
You don't seem to have played on PC in the 90s...
@@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.
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
where can I find it?
have a link to that?
@@odysseasragnarson7295 It's at 1:41:20 in this vod: www.twitch.tv/videos/1738012731?filter=archives&sort=time
@@itr00ow93 check the replies now :)
@@Anteksanteri I don't see it?
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.
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.
Uh, back in 80s we got IBM PC, Apple II, TRS-80 CoCo, Atari ST, Macintosh, Amiga, Apple IIgs, Commodore 64...
That was solved back then using bytecode interpreter or painfully port software to different platforms. Often every hardware got own software that didn't exists on other hardware.
Hardware is arguably less diverse now than it was back then. Cross-compability existed because people gave a shit about working hard to make it work.
@@neruneri
Root cause of the problem is that business idea of technology companies is to spread own proprietary technology to general use and take royalties. Starting from CPU instruction set. Avoiding that requires to make competitive option.
I don't mind that we got competition but standardization actually works well when things are simple, like character set or CPU instruction set.
Software developer should have hardware abstracted away completely or as much as possible. Exception is working on embedded scene or something where software and hardware together make product and development is optimizing watts/price down. For most of the software it should be usually problem of that platform provider to optimize how to make that abstracted software run efficiently while software developer is targetting to browser/container.
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.
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.
Hey Christopher, I wouldn't mind asking you some stuff about your job. Could we talk via dm?
Latencies add up. Fast.
@@ongeri It really doesn't matter, because IO latency makes the bulk of the waiting time. We're talking different orders of magnitude.
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.
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…
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.
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.
@@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.
@@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.
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.
@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.
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
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
Yeah. The reason why I'm looking more into ML languages and proof languages like Coq and Agda.
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.
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 Unfortunately a lot of coders are bootlickers to the tech industry. One of the worst things about this industry.
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.
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
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.
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.
No everything is complex, I think his point is that developer's are willfully ignorant about lower level, fundamental computer science, software engineering knowledge.
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.
@@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.
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.
I dunno why, but I never thought I'd see a Prime/Blow crossover 😄 My two favorite software opinion guys hahaha
A lot of good content can come from these types of crossovers.
Honestly
And maybe Casey Muratori
So you like blow?
@@nathankamenchu1239 Absolutely
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...
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".
"Why do they keep recommending me my own video?"
Cause real recognize real.
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.
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
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.
80% of being a good programmer is knowing that you're a bad programmer.
And now 100% is having ChatGPT write the code instead
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.
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.
More people having general understanding also means that there is more misunderstanding ironically
A quick shoutout to all those hobbyist bridge and airplane engineers out there.
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.
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.
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.
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.
NASA lies about 95% of what they say they do
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.
Tam Türk kafası :D.
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".
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.
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.
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.
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.
Yes, with we can ship bugfixes at the moment notice, unfortunately every such fix delivers two additional bugs too.
regarding the point about having services to contend with nowadays, the rest of this talk literally exposes this
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
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...
19:01 Most replayed. "Was that my notification or was it on the video?" 🤣
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.
18:50 TH-cam 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
move fast break things.
thats why :)
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!
18:04 There's actually a language that allows you to do that, it's called C++............😜😜😜😜
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
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.
You should react to "The Thirty Million Line Problem", it's related to this.
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.
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.
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.
I think this whole talk can be boiled down to a classic “the grass was greener back in the day” thing. I don’t know who that guy is, but at one point yt algorithm started spamming me with his videos and I watched one, where he shares his opinion about oop vs functional and it was complete bs. It was just a lot of populist well-arranged metaphors that on a surface level sounds logical but when you think about it deeper don’t stand any criticism, I see exactly this pattern repeating here.
This is clearly a case of to much game development and how it sometimes messes up someone’s brain.
Jonathan Blow is my kind of curmudgeon. Can't begrudge a person who desires to be a great craftsman.
Yoo your voice reminds me of Steve Carell but most notably him playin Gru Despicable Me. Very interesting. Subbed.
He convinced my employer, I have no job now
Good
Good news
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.
I don't feel like software's quality is inherently driven by hardware capabilities.
20 and 30 years ago, software was written proportionally to the capabilities of hardware, but was buggy as hell.
Mainly because of the lack of proper testing tools, and established standards that now prevent us from writing carastrophically bad code.
In that time, if something crashed in a program, it crashed your OS, and yet the software was proportionally smaller, so it ideally should be easier to debug and secure, yet, it wasn't.
John Blow has a lot of confirmation bias. What about all the times software works seamlessly? That’s way harder to notice. It’s easy to notice when things go wrong.
The fact that John Blow felt compelled to make this talk is indicative of the fact that software has gotten really magically good. Because of this, our standards have risen and we are more sensitive to even the smallest software failures. If most software was failing then we wouldn’t be able to notice the failures because there would not be enough successes to contrast them against. Failure can only be noticed amidst a plentiful background of successes, which is what the software landscape is today in actuality.
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.
ship software with bugs... have you met the gaming industry?
I actually get nervous where there ISN'T a day 1 patch for games these days. You know the game needs it, but it isn't ready yet so will be rushed so you're really looking at a "day 2" patch before it's actually playable.
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.
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.
I like how the video he watched cut off early, and this video cuts out early before the outro too.
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
The wikipedia page for (ml) reinforcement learning was created in 2002 and cited a 1996 book
I think the issue is that software getting more and more complex because we want it to do more and more things and we want it to be able to evolve over time. This complexity requires more abstraction and standards that lead to a lot of boiler plate. A lot of people don't like OOP because of this. However, complex, scalable software requires teams of people to manage. These teams need the abstraction to have any hope of managing and scaling the software.
The simplicity of the past was due to lack of power in hardware at that time, which was a useful constraint that can still be utilized to this day.
Now, it's replaced by "I want all the features because hardware's powerful enough, right???"
Software complexity does not match the functionality complexity most of the time. Pretty much every single bit of software you can name can be implemented orders of magnitude simpler without losing a single bit of functionality.
"A lot of people don't like OOP because of this. However, complex, scalable software requires teams of people to manage". I wonder how the Linux kernel does it, since it doesn't do OOP. How in the world does it manage complexity without OOP? In fact, how did the universe even manage to exist before OOP? I guess we'll never know.
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.
Notice how most of his examples were proprietary/private code solutions. Bcse some, if not most, of this business are not software makers, they are money makers. They dont care if their software is actually the best it can be, they care if it gives them money. Even if the programers are the best there are, most of the time they dont have the best conditions to develop properly.
But it's not because is proprietary, is because on who is their target audience: common people. Developers understand what is bad software, they understand what can be better, thats why so much developers prefer open source since we can actually see, judge and even change/fix the code, but for common people this is all magic and they cant differentiate what is simple and what is impossible, so they use whatever is sold to them. The target audience of this software is people who arent that critical and/or dont understand software enought to find alternatives that work better, so there isnt a loss of money for the business and finally there isnt any motive to become better
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.
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🎉🎉.
This proves that if you go looking for trouble you find it…. Jonathan would be a great QA tester
Deffinitely watch the talk if you can. It's quite interesting.
Me: Code 3 lines in javascript rather than rust. Prime: Maybe we trading something here, literal deal with devil.
The Android TH-cam app that I'm using to watch this video bugs about 10 times per day, freezes for more than 10 sec 2-3 times per day, crashes about once per day, and crashes the entire phone about once every two weeks or so. And all I ever use it for is watching videos, and reading/writing comments. In other words, the most basic TH-cam functionality.
MCTS + neural net approaches existed for a long time, I think he's not exactly wrong about AlphaGo being MCTS + neural net (+ advanced hardwares)
The blame is in the commidification of software development by business leaders. Businesses allow technical debt to build up with a "if it aint broke dont fix it" attitude to extract as much revenue from an otherwise subpar product. Meta didnt want to scrap their shit php code so they went so far as to build a fucking homebrew php to c++ compiler and keep their codebase in php. The result is a patchwork user experience where the transition between different technologies, as a user, is like driving over a road paved in different materials with different textures and colors.
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
Opening task manager and ending your task was a completely normal and expected user task in Windows more than 20 years ago. So I find this a poor argument for software being on decline. More people user more software daily than ever. I’d argue that software today is more resilent and fails less than ever before when you weight how much people use it compared to before. Fails per cpu instructions has probably gone way down. I think people have to be mindful of cognitive bias here.
The new Counter-Strike UI, Panorama, is indeed written in XML and JavaScript and runs in V8/CEF.
The base layer of software is economics, but our economic system is actually ponzinomics.
You see this degradation of quality everywhere. Remember when Chipotle was not disgusting? Eventually a ponzi runs out of steam and I think that is really what we are witnessing.
He also completely missed the point that today most businesses don't even know what they want with companies the next day, let alone years ahead... Most customers expect CHANGES at same day speeds, because it's just easier to "try it in prod", then planning and figuring it out.
also, this sounds exactly like the stuff Bob Martin was talking about 20 years ago.
Blame MVP and Agile not us, most of my time is spent arguing with MBA project managers suits, how *this* doesn't make sense and if we do it this way instead of taking the time it can introduce a bug where if a user moves to 24 then 22 then 20 it would ring the phone, "we will fix that in the future, I need to show the client and make money now, what is the odds of that happening?"
I simply gave up I don't want to argue with my clients all the time it's exhausting.
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 TH-cam 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.
"The layers of abstractions and problems have greatly grown in comparison to 30 years ago" -- exactly, but there are the problems related to the actual problem (transforming data_x into output_y), those problems that are necessary and unavoidable, and there are those unnecessary problems, not required by the actual problem, that have been created by many things, not the least of which is the added/unnecessary abstraction (which isn't the same thing as saying that all abstraction is unnecessary). Where I've seen many disagree with Blow is in defining which abstractions are necessary and which aren't.
Saying software is slow because of all these new problems and abstractions and black-box libraries, etc... is actually to agree with Blow. The question then is "what to do about it?"