Well, there are a few reasons. Before I begin though, it's probably best I mention that every industry has its faults. The difference in a lot of cases is merel

Well, there are a few reasons. Before I begin though, it's probably best I mention that every industry has its faults. The difference in a lot of cases is merely between fixing all the ones normal people would encounter in every day life and trying in vain to fix everything. You'll never do the latter in a million years. But the difference is likely that: 1. Time frames are quicker in IT fields, especially web development fields. So corners are cut and things are rushed to get them out the door. Same deal in games, where publishers assume they can release now and patch later. 2. There are stricter regulations in other fields. Not surprising cause they need them, the consequences are higher if things go wrong. Meanwhile IT projects (especially on a smaller scale/outside the finance industry) can be summed up as 'if it works, it's good'. Same with game development. 3. Human attacker risks are lower in many fields. This comes down to two things: A: There's less of an incentive to 'test' non IT projects. For IT stuff like sites, breaking them can mean money from bounties (at the good end) and data to sell to criminals (on the negative end). For games, it can mean distributing pirated copies via torrent sites or gaining access to the console hardware. For an aeroplane or building? Why would anyone need to find faults? At least outside of internal testing or certification services... B: It's much easier for them to find faults. They can attack an IT project without leaving the house, and they obviously have physical/file access to any games they own. No one has easy access to test buildings or large vehicles. 4. The risks provide a greater incentive to 'do things right'. If the worst that can happen is a site crashes/gets hacked, or even that the user finds a few random small bugs, there's less of an incentive than if the risk is loss of life or a huge financial loss. 5. A lack of standardisation or 'best practices'. People know what's good in vehicle or building design, and most are very much like others of the same type. Websites are mostly unique from each other, and games are often similar. There's a lot more uncharted territory there. 6. Careful planning is more common in some fields than others. A plane or building is probably not going to be revised very much, especially if there's no pressing reason to revise it mid development. A website or app may well be (especially if the client keeps changing them mind), and a game often will be as well (if something either isn't turning out to be fun, or the management decide the latest hot idea has been incorporated now). So the time available for testing and proper development can be limited due to constantly changing demands. And yes, I feel the 'managing complexity' aspect brought up by static_noise is relevant here too. It's easier to figure out what each part of a mechanical system does than it is to do the same with a computer program or script. That's why large sandbox type games (like say, Zelda Breath of the Wild) can get rather buggy if you try unusual things. Because no Q/A team on the planet can find every odd thing a player could try and get the developers to implement a logical response to it. No one's going to find stuff like that which Stryder7X shows in his videos without being either going well out of their way to try insane things or being shown them: https://www.youtube.com/watch?v=XFWjGXmnpno https://www.youtube.com/watch?v=XFWjGXmnpno Either way, there are lots of reasons really.