Software Engineering Myths Debunked
What are some popular software engineering myths?
1. Popularity is strongly related to quality.
For me, this is the biggest, most pernicious myth. Programmers casually assume that if a technology, idea or language is popular it must be good and if it is not popular it must be bad. Often, people implicitly equate success with popularity. Commonly, this myth is internally rationalized with circular reasoning:
A: Oh, if popularity is not related to quality, name something popular that’s bad.
A: Ah, but if PHP is so bad, why do so many people use it? Checkmate, atheist!
In reality this thought process is more complicated, less obvious and not self-parodying, but that’s how sophistry works. “Worse is better” is practically a moral system built up on this idea and it’s buoyed up by thought-terminating clichés like “the right tool for the job”. (Which crops up in 90% of all discussions about programming language quality)
Of course, popularity is no better a signal in software than anywhere else. It would be like believing McDonald’s the pinnacle of cuisine and Pop music the pinnacle of composition.
More importantly, there are systematic, scientific reasons to believe that the popularity of anything is largely not based on its intrinsic qualities. Instead, popularity is a function of social networks. If you are not convinced, have a look at why some programming languages succeed in defeating programming language inertia and become mainstream, while others don’t.
2. C makes your code fast.
C lets you write fast code, but slow is still the default. C is not a magic elixir of performance that you can sprinkle over your code. It merely lets you access low-level knobs to speed your algorithm up if you know how to use them. In particular, just compiling a high-level language to C will not make it as fast as C.
3. Floating point numbers are real numbers. (In either sense of the word “real”.)
Floating point numbers behave in incredibly weird, unnumberlike ways, but unless accuracy is critical programmers pretend they do. It’s fine most of the time — just never store money in a float!
4. Unicode is evil.
⛤Actually, this is basically true.⛤ But support it anyway because we don’t have anything better.
5. Instructions from multiple threads are interleaved with each other.
That’s what I used to think: two threads can be interleaved in any way, but instructions from a single thread always happen in the same order relative to each other. In fact, this only holds from the perspective within a thread — the processor is free to reorder instructions inside a thread in a way that’s visible to other threads. I learned about this from a talk about verifying the Java memory model — it’s rather complex but tame by memory-model standards.
6. C is a functional language.
No! C is a procedural language — completely different, but I’ve run into a surprising number of people who never learned about functional programming formally and assume that it just means “not object-oriented”.
7. Category theory makes no sense.
Category theory makes some sense.
8. Pure functional programming means you can’t have IO or effects.
You can have all the effects you’d like in a pure language like Haskell — they’re just marked off explicitly from normal code. More generally, there are lots of myths about functional programming. Think “Functional Programming” is a thing? It isn’t. It’s one of the worst-defined terms in CS — maybe even worse than “OOP”, but a tad better than “declarative programming”. Figuring out whether a language is “functional” is an exercise in anthropology, not computer science.
9. Programming language designers are indistinguishable from serial killers.
In fact, most programming languages are refreshingly murder-free.
10. The other person’s code is crappy
Maybe. It’s more likely that either they wrote it to solve a problem other than the one you’re trying to solve, or you simply don’t understand the intricacies of the problem.
11. It’ll be better if I just rewrite it in a different language using a different architecture.
No, you’ll likely just end up with a more bugs than the previous piece of software.
12. I’m a rockstar.
Careful, you may just churn out something ‘extremely epic’ over the weekend and your poor peers spend the next month picking up the pieces (coding the error cases, tests, etc.) resulting in poor moral and productivity on their part. If ‘being the smartest and best’ results in a net loss of team productivity, you’re not a rockstar.
13. Process is stupid, I’ll just write the code.
Process helps set expectations of management, customers, and so on. Without that, you’ll just end up doing the death march thing.
14. I suck at this.
That’s just called imposter syndrome. It’s usually a sign that you’re learning something new. Learning new stuff is good. And yes, even I suffer from imposter syndrome from time to time, and I’ve been doing this for a long time now and have produce good things.
15. Real programmers code in C.
No. Real programmers code in whatever language best solves the problem.
16. Young people are the best programmers because they have energy and creativity.
No. They’re just less expensive. They may be exceptional, or not, but that’s not an aspect of being young.
17. Old people are the best programmers because they have experience.
No. It’s not about having experience, it’s about how you use it. And the best experience is knowledge about ones own strengths and weaknesses.
18. Well, it works on my machine.
If someone reports an issue, and you don’t take them seriously, you may end up with some unfortunate surprises down the line when your software is deployed and users run into the same problem.
19. Users are stupid.
If they choose not to buy your software because you’ve shipped them something that’s hard for them to use, then you’ll ultimately be the one with the problem. They won’t buy your software.
20. VI is better than Emacs.
No. Emacs is best. Period. Better than VI. Better than Eclipse. Better than Visual Studio. Better than Xcode.