• The Waterfall Method of design, the idea that it is both possible, efficient and good practice to completely specify a system before building it, and to execute the steps of a software project sequentially rather than iteratively. This was popularized by a paper that described the method as an example of poor development practices, but which people took as an example of good practice: http://en.wikipedia.org/wiki/Wat...
• That customers or end users will know what they want and will be able to articulate it.
• That some language, technology, or popular method, other than the one you are currently using, is a silver bullet that will magically solve your problems.
• The Mythical Man Month, the idea that adding people to a development team makes it more efficient in a linear fashion. http://en.wikipedia.org/wiki/The...
• That coming to agreement on a specification means agreeing on the actual features, even though specifications are fuzzy and subject to different interpretations. http://gettingreal.37signals.com...
• That development works best when there is just one way to do it, where programmers freedom is severely restricted by the language.
• That development works best when there more than one way to accomplish a task, where programmers have complete freedom.
• That design patterns are universal, rather than examples of limitations in the expressiveness of particular programming languages.
• That the best technical solution wins.
• That you can parse HTML with a regular expression: http://stackoverflow.com/questio...
• That marketing doesn't matter, and is best left to "suits".
• That software can be estimated accurately.
• That software development can be effectively and profitably sold as fixed cost, fixed timeframe projects.
• That objects are the best way to model anything in the real world.  That modeling real-world entities is the way objects are most commonly used.
• That data should always be hidden within objects, and the object should provide all the operations necessary to work with that data.
• That JavaScript has something to do with Java.
• That logic can and should always be completely separated from presentation.
• That software development is mostly about having good math skills, is best taught by studying theoretical computer science, and is best done by people who are highly mathematical.  That solving logic puzzles is the best way to gauge a software engineer's ability.
• The idea that software is mostly about what's visible on the surface, and that what is happening underneath the design isn't worth paying attention to or understanding—a belief especially held by nontechnical managers and clients.
• That writing software is a good profession for people who lack people skills.
• That software can be effectively mocked up or designed in some other medium, such as wireframes or Photoshop comps, because designing in the actual medium (such as HTML and CSS) is too hard and expensive.
• That designers can't or won't learn any coding, and must be protected from real code.
• That design is just a layer of decoration applied on the surface, and is much less important than good engineering.
• The idea that software can be reliably built up on a stack of abstractions, and that you only need to understand the topmost, abstract layers, rather than the underlying implementations.  See Joel Spolsky's Law of Leaky Abstractions for a discussion of why this is a myth: http://www.joelonsoftware.com/ar...
• That when you finally release your new app or website, you're done.

Author : Lee Semel, Source : http://www.quora.com/What-are-some-popular-myths-in-software-development