No one here is talking about the one thing that, to me, is the most obvious reason for why software sucks so much: excessive complexity! The more complex a system becomes, the less people understand it and the more hidden problems become.

Many people would agree with that statement in principle, but most people don’t appreciate the scale of the problem. If a system is anything more than dirt trivial, it is too complex and many people won’t be able to *fully* understand it. The problem is that small degrees of complexity in the system results in much higher degrees of complexity in behaviors. It follows a square law or even a cube law--if you double the number of components you may quadruple or more the complexity of the behaviors that can arise.

There’s a general consensus that simplicity is easy and complexity is hard. This is true about *using* something. But when *building* something, in fact the reverse is true: complexity is easy, and simplicity is hard. It is easy to make things more complex. Inexperienced programmers do it every day: add an extra “if” statement, add another global variable, add another flag, add another special case to generic code, add another button or checkmark or option to a user interface. The real challenge is adding functionality without adding complexity. It requires periodically taking a step back and re-evaluating what is common, what is special-cased, and what natural organizations make sense in the structure of the data and the operations performed on it. It sometimes requires complete reorganization when it is discovered the current organization doesn’t work for the new functionality, or redesign when the existing abstractions don’t fit a new feature. It is very hard to make and keep things simple, but the rewards are worth the effort.

If you design a complex program using a large number of global variables and a large number of “if” statements reacting to events, and at some particular moment in time I ask you “what is the current state of your program?” what would be your answer? What does “state” even mean in this context? A program with many global variables and many event-reactive functions employing many if-statements can have a massive array of possible states. An event arrives, a handler function for that event enters numerous if-statements based on both the input event data and numerous variable values, some output is produced, and some of those globals change, placing the code into a new state. The number of possible states is going to be the product of all the possible code paths being taken due to different combinations of global variable values. This product can easily launch into the millions.

I refer to this as “combinatorial code”. (See the mathematical study of “combinatorics.”)

You might think, “this is interesting from a computer scientist writing on a whiteboard in front of a class” perspective, but what does it have to do with me? Here’s what it has to do with you: Have you tested all the possible states in your code? Can you definitively state that your code will behave correctly in every single one of those several million possible states? Could you ever prove conclusively your code is correct?

The part that frustrates the hell out of me is when I see software being made really, really complex FOR NO REASON. I’m working on a project right now, taking an application someone else wrote and porting it to a new hardware platform, and I’m really frustrated because there are layers upon layers upon layers of framework and abstraction, but if you isolate the parts of the code that do “real work”, it’s like 10% of the code, maybe even less. There’s sooo much weight around the real code that doesn’t do anything. No wonder it took a team of people a couple of years to hammer this thing into a workable state before I had the misfortune of porting it to another platform.

It is really easy to make something complex and difficult to debug. It is really hard to not only make something simple, but KEEP it simple after years of new features.

I'm seeing almost noone here discuss the center channel! My TV set will not send anything but stereo sound down to the receiver, even though the source audio is in 5.1 surround. I think when using Netflix or Prime apps on my TiVo there's 5.1 coming out the HDMI port going into the TV but the TV won't send the center down to the receiver on the ARC, nor on the TOSlink (the TOSLink appears to be **STEREO** **ONLY**, is this 1970?!) [*]. Some DVDs & Blurays have options for different audio channels, and some Bluray players have options for it (but some don't work), and some don't have the options at all.

The first place I noticed this was on a DVD of the year 2000 Shaft (Samuel Jackson) because at the time the only place I could watch it was on a PC, and I missed >90% of the dialogue. Tried it on a friend's DVD player and all the dialogue came out perfectly fine from his center channel.

I've seen devices with an option to "mix center channel into stereo channel" and that helped a lot, but most devices don't have that option. I think there's a lot of problems in the AV equipment world with the center channel -- and if you're just using Airpods on an iPad watching the Prime Video app, you don't have any options to get that center channel.

[*] So now you're saying why don't you plug the TiVo into the receiver and the receiver into the TV instead of plugging the TiVo directly to the TV and using TOSLink or ARC? Well, because the stupid TiVo HDMI craps out after one day because the receiver won't forward the HDCP authorizations back from the TV unless the receiver is on all day long and set to "TV" all day long. Figured that one out the hard way. Maybe a newer receiver with newer HDCP compliance can fix that, but I'm not spending that money on a whim.

i laughed out loud when i read "safe for use in the human body." i don't think they know what's usually meant by that term.

they've apparently determined the battery is safe from the human body (holds it's charge in the chemical soup of the blood, etc).
they've most definitely NOT determined that the human body is safe from the battery (nor anything that might be attached to / powered by the battery).

what if you've got a few million of these in your blood and they start sticking in your liver? what do they do to the nephrons of the kidney? what do they do to the alveoli of the lungs? i don't expect to see these things inside a real human for any reason for years.

How is this different from just about every other type of software development sector during COVID?
How is this different from just about every other INDUSTRY ON EARTH during COVID?
I'm a software guy (not gaming) at a job where you have to be in the office (kind of hard to put your hands on embedded hardware units and $300k analyzers at home) and everyone I know is struggling with childcare and other issues; I know people working half of their >40 hours a week of software and hardware engineering on late-night evenings and weekends just so they can coordinate with their spouse on who stays home with the kids, which is especially difficult given that their schools are kind of random week-to-week as to whether their kids are half-day in school, half-day at home on zoom, or full day one, or full day the other, or that one kid is in school at the elementary school while the other kid is zooming at home from the jr high, and the next day it's reversed. Frankly, it sounds like a nightmare.
Why is this specific to the gaming industry, what is IMHO the second lowest tier of all software engineering ever (next to automotive of course)?
Forget software altogether, just be thankful you have a job. Before the pandemic one of my friends worked two jobs, a restaurant server, and a massage therapist. Guess what he's doing now? Neither of those, that's for sure.

A lot of commenters here seem to be (incorrectly) conflating code which DOES math with code BEING math. Yes there's a lot of products that need high math (i.e. simulations) but there's also a lot of products that are successful when they do extremely complex data movement and organization but very little mathematical transformations.

If programming was so close to math, wouldn't people who are really good at math write the best code? Maybe that's a straw man statement, but in my experience, the people who are really REALLY good at math (e.g. the radio frequency signals processing guys) happen to write the worst code I've ever seen. I've spent much of my career taking prototypes written by DSP engineers and making them go 10 to 100 times faster and use a tenth as much memory. That's not belittling their skills! They did something absolutely amazing that I cannot do, coming up with the steps and crazy weird math required to process signals. (And often, even though I make their code go way faster, I still don't really understand the math behind it when I'm done.) Their code just happens to not take proper advantage of the hardware or other resources. They do the equations so it *functions*, but they don't know how to make it *fast*.

The real skill comes from being able to picture the structure of the data in your mind as complex interconnecting shapes and mentally animate the movement and transformation of data in as few steps as possible without redundancy or useless or redundant transformations; and in many cases, being able to picture multiple workers doing their work in parallel is a plus. I'm not saying every great programmer uses their visual cortex, just that they can keep track of a lot of moving pieces in their mind.

This isn't math. This is more like a visual/spatial skill, like a mechanical engineer designing a complex machine with a lot of moving parts that have to fit together perfectly and move through each other's space in perfect timing. I think it's a different part of the brain from either math OR language.

I have to agree with Kun that complexity analysis (big-O) is absolutely mandatory, though. Saying complexity analysis is "pretty much meaningless" is the dumbest part of Mei's article. Kun also makes good points about recent innovations in DSP, machine learning, etc come from math--but only the *theory* part. You still need people good at the mechanics of programming to *implement* that theory in a productizeable way.

I would like to ask a stupid question. If my employer is doing this, and I'm using Chrome to look at, say, https://mail.google.com/, when I click on the little green lock next to the URL to view the Certificate Information, and my company's name is NOT present (the cert path is GeoTrust Global / Google Internet Authority / mail.google.com) can trust that to mean my company is not intercepting that traffic? Or can my company make it appear this way and still be intercepting my traffic? I suspect there are a number of people who would like to know the answer to this. I'm hoping it's not as stupid a question as it sounds.

Exactly. This was posted on gizmodo last week, and the site crashed shortly after that due to the click load. The comment I made at the time was: It is one thing to build a nice web site with a nice interface. It is quite another to build a nice web site that talks to a real database. It is quite a third thing to build a nice web site that talks to a real database and can handle a thousand users. It is quite a fourth thing to build a nice web site that talks to a real database and can handle a million users. It is quite a fifth thing to build a nice web site that talks to a real database and can handle a hundred million users. It is a sixth thing to do all that and talk to 50 databases. It is a seventh thing to do all that and talk to 50 databases managed by a hundred different state agencies and insurance companies who can't all seem to read an API spec the same way.

My biggest problem in getting my patent applications approved has always been "enforceability." One example was a method for maximizing PCI bus utilization in a many-board CompactPCI cage (it was a sort of token-distribution method for preventing wait-cycles and bus-to-bus bridge fifo overruns, kind of silly in retrospect). The patent review board looked at the stuff I've written and says "yeah, that's a really good idea, but how would you ever detect that a competitor's product is violating it?" Which is a good point, about the only way you'd know is by connecting PCI analyzers to the backplanes of every PCI product known to man and spending hours on each one analyzing traffic trying to figure out if they're distributing tokens or somesuch. So based purely on the grounds of the idea, they would have been willing to pursue it, but given that we never would have been able to tell if someone else's PCI-based product was doing it, they didn't think it would be worth spending the tens of thousands of dollars it would have taken to push the application through. It wasn't long after that that I realized the flipside of the coin is also true. If I am coding something like this, how would I know that someone already has a patent on it? There's a million different ways to describe it (anything from "token flow control method on a shared memory bus" to "method to increase multiple queue throughput") and many may apply without even using the words "PCI" or "flow control" or "token" -- so how would you ever possibly do an exhaustive search of the literally millions of SW patents out there? The answer is, you don't. You just have a large well-paid legal staff that can fight off any tom dick or jane who thinks their poorly-worded patent somehow can be twisted into applying to your product. I'm pretty sure the average developer writes at least one thing every month of their careers which violates some interpretation of some patent somewhere. The patent system exists for the purpose of encouraging creative people to come up with creative ideas, and then protect and profit from those ideas. Given the limitations of the software patent, and the vague genericness of ridiculous software patents, it is obvious that software patents are completely incapable of meeting those goals. Smart people don't file for patents for creative things they done. SW patents have completely degenerated into handguns & bullets for large companies : when a company wants to (indiscriminately) impact the pocketbook of another company, they just load up some random SW patent and pull the trigger. They're not used for protecting creativity. They're used to force a court to force a competitor that they don't like to cough up huge wads of money.

As the piston goes up and down, the piston's angle with respect to the piston rod is changing. Before the piston reaches top-dead-center (on the upswing) the piston is pressing mostly against one side of the cylinder. After top-dead-center, it rocks over on the wrist pin so on the down-swing it is now pressing mostly on the other side of the cylinder. I always thought knocking was because this transition was more violent due to the early combustion increasing the amount of pressure on the piston too early.