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.