I’d say that software engineering is more like writing a novel or essay. I’d say it has more in come with Linguistics than Math or ‘Real’ Engineering.
There are multiple ways to do Task A in a program as there are multiple ways to write Paragraph A in a story. Writing usually has some sort of syntax that it follows. Programming languages also enforce a syntax.
There are some exceptions but even those are covered in software engineering when we decide to design our own scripting language for our program which is ultimately parsed by a syntactic language anyways.
When we read source code, we read it top left to right and go continue on the next line, left to right, until we get to the bottom. (generalization, of course). Sometimes we jump around to follow the flow of the calls. Literature is like that as well. Some literature or source code is very simple and flow into each paragraph or function seamlessly. Other types of literature force the reader to jump around, as does source code.
As with the logic, one can write out a novel about math. We can write out math and express it in words. If the literature doesn’t specify how to process the math, we have a general idea on how to process it. X = X + 1 means we take X and add 1 to it. However in a book about math, ‘+’ could have been defined as substraction. We can do the same in software engineering.
With so many different ways to effect a single outcome there is only one best answer; mathematically determined to be the most efficient. Software engineering is measurable; running code can be optimized. What distinguishes civil engineering from practical engineering is not the nature of the solution but the specificity (and relative elasticity) of the requirement set.
I need a two-lane highway bridge across this river at this location to support up to 20 metric tonnes concurrently in each direction at up to 200 km/h implies a larger set of knowable facts (substrate and construction material properties, climate history, …) which is distinctly different from we need a faster way to process credit card transactions.
Software engineering is engineering; those who choose to declare it an art have chosen to ignore the physical realities of the processor. Software requirements definition is certainly not engineering, hardly a discipline, looks like an art, and intrudes the realm of pure magic.
This is a wonderful discourse, much like the ones that happen in software design sessions! Obviously there are no absolutes here, wrong or right.
I agree with the comments about the engineering disciplines facing many of the same challenges as software developers face in terms of the torrent of changes brought about by the relentless expansion of human knowledge. I believe, however, that the lack of predictability (and sometimes reliability) in the software process can be compared to the challenges of the bridge builder IF you impose the condition that the builder will have to use materials whose characteristics and provenance that are unknown, and will have to invent and build many of the subassemblies that will be used to actually construct the bridge.
Even in the case of web applications, much of the software developer’s challenges come from having to explore the performance, reliability (or lack of) and behavior of an enormous stack of technologies on which to base his application. (For now, we can ignore the very real challenges of building software to satisfy whims instead of requirements.)
Even in the very early days of non-mainframe development, your code had to be based on the (often poor) assumption that the functions you invoked in your code actually would behave as documented. What we consistently underestimate is the accumulated instability of the many layers of technology that underpin even the simplest application software.
Software is based, at the very bottom, on bits, and they are entirely well-defined, objective, and determinate. Pure logic is as solid a foundation as can exist. The higher-level rules that follow are not well known. But it would be odd to suggest they never will be better understood. It has only been about 50 years. Even at the current state, the essential consistency of the medium allows substantial and detailed manipulation.
And looking at it from the other end: engineering is, roughly, assembling functional (ie. useful) parts to make functional wholes. Or slightly closer: assembling pieces by knowing/understanding their properties to a good degree, and using experiment here and there to fill particular gaps. When you build a web-app, for example, that is exactly what you are doing.
Certainly, software has special characteristics, but overall it is more engineering than not.
What I see missing in the comparison between building a bridge and software development is that the actual construction of the bridge is in most cases the shortest part of the project. Long before anyone starts construction they begin with an initial idea, then there is multiple reiterations of survey, design and review. This allows the engineer to make sure the bridge will meet the current and future traffic needs. In other words they begin by gathering requirements, then create their initial design, have that design reviewed and approved by everyone and anyone impacted by that bridge (city officials, citizens, federal government, etc).
After the final plan is approved, then they determine the materials, labor and equipment needed. Only then do they begin construction.
Yes they do have design changes as well as other problems arise that change one of the project constraints. This is an expected part of any project.
My experience in software development has taught me that I need to spend more time defining the problem, gathering requirements and design before I begin coding.
I’ve always thought programming was similar to the proofs I had to do in high school Geometry, which was some of the only high-school math I really enjoyed. You had to solve a problem and write out every step of how it was done. Sometimes you had to graph it. There were multiple solutions to problems. I remember I was considered weird for being one of the few people who liked math word problems while everyone else always groaned about them. But it made it more visual for me and I’ve always been good at art and language.
On the other hand, I remember detesting Algebra and Trig. I’ve tried really hard the past few years to really like math, as it is the language of the universe and super useful…but I really don’t consider it “fun”. I’ve never even liked Sudoku.