Comparing software engineering with civil engineering, I was surprised
to observe a different way of thinking: any civil engineer knows that
if you want to build a small hut in the garden you can just get the
materials and go build it whereas if you want to build a 10-storey house
(or, e.g., something like this) you need to do quite some maths
to be sure that it won't fall apart.

In contrast, speaking with some programmers or reading blogs or forums
I often find a wide-spread opinion that can be formulated more or less as follows: theory and formal methods are for mathematicians / scientists
while programming is more about getting things done.

What is normally implied here is that programming is something very
practical and that even though formal methods, mathematics, algorithm theory,
clean / coherent programming languages, etc, may be interesting topics,
they are often not needed if all one wants is to get things done.

According to my experience, I would say that while you do not need much
theory to put together a 100-line script (the hut), in order to develop
a complex application (the 10-storey building) you need a structured
design, well-defined methods, a good programming language, good text
books where you can look up algorithms, etc.

So IMO (the right amount of) theory is one of the tools
for getting things done.

My question is why do some programmers think that there is a contrast
between theory (formal methods) and practice (getting things done)?

Is software engineering (building software) perceived by many as
easy compared to, say, civil engineering (building houses)?

Or are these two disciplines really different (apart from mission-critical
software, software failure is much more acceptable than building failure)?



I try to summarize, what I have understood from the answers so far.


In contrast to software engineering, in civil engineering it is much clearer what amount of theory (modelling, design) is needed for a certain task.
This is partly due to the fact that civil engineering is as old as mankind while software engineering has been around for a few decades only.
Another reason is the fact that software is a more volatile kind of artefact, with more flexible requirements (it may be allowed to crash), different marketing strategies (good design can be sacrificed in order to get it on the market quickly), etc.


As a consequence, it is much more difficult to determine what the right amount
of design / theory is appropriate in software engineering (too little -> messy code, too much -> I can never get finished)
because there is no general rule and only (a lot of) experience can help.

So if I interpret your answers correctly, this uncertainty about how much
theory is really needed contributes to the mixed love / hate feelings
some programmers have towards theory.

I think the main difference is that with civil engineering, real world physics act as a constant, powerful reality check that keeps theory sane and also limits bad practices, whereas in software engineering there is no equally strong force to keep impractical ivory tower concepts as well as shoddy workmanship in check. 

Many programmers have had bad experiences with runaway theory becoming an active impediment to getting things done (e.g. "executable UML", super-bureaucratic development processes). Conversely, dirty hacks and patches can get you pretty damn far, albeit slowly in the end. And as you observe in your last paragraph: failures are usually not as final and thus not as problematic.
