Yes, but it’s not as hard of a constraint like physical constraints in other engineering disciplines.

Memory usage, processor power, hard disk space, network speed, and more are constraints. However, there are two considerations. First, they are easily expanded. You can add additional resources or distribute the problem across multiple nodes or upgrade hardware components, for example. Second, your software can exist on multiple platforms with different characteristics because it is so easily copied and put into a variety of different environments. Neither of these are true of many physical things.

In addition, you can write code ignoring these constraints. Eventually, it may work if you move it to a more appropriate environment or wait for hardware to catch up. You can’t simply take, for example, a bridge and move it to a new river crossing because it didn’t work in the first location you built it.

As whatsisname points out in another answer, some software engineering efforts do have physical constraints. Anything that lives in the physical world is likely to have physical constraints – many embedded systems or control systems, for example. However, with respect to all of the code written, this isn’t a whole lot.

I’d generally agree that software engineering is different than other engineering disciplines rooted in the physical world, but we do have constraints other than our minds. Beyond the project triangle that impacts any engineering projects, we often deal with improving legacy projects and are constrained by various past decisions.

Aren’t the above situations just as challenging as physical constraints talked about in the video?

They can be, but for most developers and projects, they aren’t.

Some software is written with serious, hard restrictions on speed, memory, space, etc. If you are writing the software for the space shuttle guidance computer, where you have a specific task to perform, have specific hardware it will run on, and your “business logic” consists exclusively of manipulating physics equations, then the constraints you face as a software developer for that project are facing physical constrains much the same way the engineers for the rocket motors are.

On the other hand, if you are working for a company writing software to schedule dentist appointments, for the most part your physical constraints completely vanish. You can give almost no thought to how much space or memory your program is using, and chances are you’ll be just fine. Dates and times is a subject of great woe for many software developers, and yet, since most dentist offices are only open during regular business hours, you can be pretty sloppy handling dates and get by just fine for years. When you tie in billing, and connecting to insurance providers, you have to work with constraints that aren’t dictated by the laws of the universe. Instead, your constraints have almost no basis in reality, and are instead an incomprehensible unholy conglomeration of what dozens of MBA types thought were good ideas at dozens of different times concerning vaguely related subjects. All of which can be bent or overridden with a managers approval.

A small handful of software developers work on stuff like the space shuttle software. The vast majority are working on stuff like the scheduling software. If you try to build the dentist software to the standards for the space shuttle, it will take you 70 years and cost a trillion dollars, and won’t be noticeably better than the competition.