In ancient Egypt, pyramid-building must have seemed the unbelievable pinnacle of human achievement, only surpassable by ever higher and larger pyramids. Only now we see the primitiveness of those works (notwithstanding their merit and value).
It is my take that our current level of understanding of software building is similar to the that of architecture when pyramids were built.
Fortunately, advance is now much faster thanks to the many tools that help experimentation and communication, and we should be approaching somewhere reasonable in just a few decades.
If you mean "the theoretical underpinnings", then, yes, we think we do. Turing machines and Church calculus provide solid theoretical underpinnings, that (as far as we know now) are complete. (Of course, the future could show us that they are incomplete. That's the problem with knowing whether your current understanding is proper - you don't know what gaps the future will reveal.)
However, if you mean "we know how to build programs so they work", there's massive empirical evidence that says that we don't. (That is, we can do it... sometimes. And sometimes we can do it after it takes five times as much money as we expected. And sometimes we can't make it work, ever. And we can't tell up front which will happen.) So in terms of this being engineering - as opposed to computer science - saying that we don't properly understand the fundamentals seems like an entirely reasonable statement.
Both ends you describe (computer science and software engineering) are to me part of the same continuum. We still have articulate most of it with a coherent theory.
A software engineer knows about the capacity of a server? With what I/O rate, TCP/IP data rate, memory locality of reference, independent threads, memory that can be effectively cached, the memory usage, errors and their consequences?
E.g., one of the problems of doing optimization of assigning programs to servers in a server farm is knowing what (1) the servers can do, also considering other programs the server is running, and (2) what resources the software needs, and it's too tough to know either and, then, in a significantly large and complex server farm, fully to exploit this data for full optimization.
Software engineers are working with at best rubber specs on both the resources they have and the resources they will be using. So, can't really do engineering on the work, e.g., really can guarantee next to nothing. Or, would you want to bet the life of your wife or daughter on some software doing its work without errors and on time? Neither would I!
