What are the biggest programming myths?

“1.- We’re always wrong.” 

SometimesWereWrong + SometimesWereRight != “We’re always wrong” 

“2.- If something can break, it will break.” 

Good thing this isn’t true. I’m am continually amazed that some of the crap I have to maintain ever ran in the first place, much less that it continues to run. But it does. Sometimes for years without ever breaking. I call it “dodging the raindrops”. 

“3.- All code is crap.” 

Whoever said this must have never seen really magnificent code for him to say this. What a shame. It’s out there. 

“4.- There is always a bug.” 

False. The first step in writing bug-free code is believing that it’s possible. 

“5.- The most important thing is the client.” 

Lots of things are important, but it’s hard to argue with this one. 

“6.- Design on paper doesn’t work.” 

Sure it can. Just because it usually doesn’t work doesn’t mean that it can’t. I prefer prototyping, but blueprinting can be effective too.

 “7.- Less is more.” 

Generally, yes. That’s what great design and refactoring are for. But there are counterexamples to this. 

“8.- Coding is only 20% of what we do.” 

If you actually believe this, then you’re not spending enough time coding. I’d say more like 50 to 80%. 

“9.- The customer doesn’t know what he/she wants NEVER!.”

False. The customer often knows “exactly” what he/she wants, but may have trouble communicating. That’s when you expert analysis and prototyping skills come in handy.

“10.- Someone has done it before.” 

Similar to #4, the first step in inventing something new is believing it’s possible. Lots of stuff that needs to be done hasn’t been done for all kinds of reasons. Maybe no one thought it was possible or no one has understood its potential. But we know better. 

“Bonus: Hey! Our job is cool!” 

Yes! I agree!