The biggest myths in software development

Throughout my work experience, I’ve seen many misconceptions about software development that can harm teams and companies.

Published in

CodeX

11 min readOct 29, 2021

All the advice follows The “Just Sharing” Principle. Some might be subjective, and others might challenge your beliefs, so I hope you keep an open mind. I recommend exploring the links.

Product

“The more features, the better”. The best tool is not the one with more features but the one that better matches users’ needs. Having all features makes your product average for everyone. “Feature creep” hinders UX, marketing, and codebase maintainability. “Complexity probably increases as the square of the features: double the number of features, quadruple the complexity. Provide ten times as many features, multiply the complexity by one hundred.” — The Design of Everyday Things.
“The cost of a feature is its development”. All of us have heard: “But it's just a button”. There’s so much more besides the development costs when building a new feature: hardware costs, the added weight to the codebase, and the impact on documentation and training, among other fixed and variable costs.
“A product always needs instructions”. The UI should not depend on some user manual to be used. Adding instructions is just a band-aid. If you need to explain it, you’re doing it wrong. Instead, try to solve the root issues. Iterate the design further rather than sticking to the first solution; aim for self-sufficiency.
“If users can’t do some task, it’s their fault”. This is one of the most common design myths. I keep listening to developers patronizing users, which is annoying. If your users can’t accomplish some task, it’s probably your fault. The team needs to acknowledge it, learn from it, and iterate to make it more usable and inclusive.
“Product owners know what the customers want”. Be skeptical of internal people who know what the customer wants (product owners, product managers, etc.). They’re not the authority and don’t have a crystal ball for customer needs. Continuous user research and feedback are fundamental, or you’re just doing guesswork.

Process

“Estimation is fundamental”. Estimation is generally a waste of time and a source of anxiety. Estimates are usually wrong. People fight over ‘1’ or ‘3’ in long, energy-draining meetings for nothing. Use that energy to understand the stories better and to split them into small bits with value. Once they’re small, they’re roughly the same size anyway. Why do people want estimates? Collaborating with customers and delivering frequently is how we reduce their delivery anxiety.
“Agile/lean is making things quick and dirty”. Agile is not about increasing speed or reducing quality. Agile is delivering sooner, not faster. It’s about reducing the risk by regularly delivering small value for the users and acting on their feedback. Lean is a set of 7 principles, including waste reduction, postponing decisions to the last responsible moment, and team empowerment. There’s nothing there about low quality.
“Agile is a methodology”. Agile software development is simply about our daily approach to problems: user-centered development, empowering teams, delivering small steps, experimentation culture, reducing waste, etc. Some methodologies embody some of its principles and practices (e.g., XP, DevOps, Kanban, Lean, CI/CD), but agile is primarily a frame of mind, not a set of rules. You don’t practice agile; instead, you are or aren’t.
“Doing Scrum is being agile”. Agile is not a methodology or a certification. You may be doing Scrum by the book and still not be agile. Agile is rather the opposite: it’s constantly adapting. Beware of gatekeepers who say you’re not agile if you're not doing some sacred practice.
“Using JIRA is being agile”. Agile is not a tool; it’s a cross-company frame of mind. Start by defining your values and principles. Ways of working, processes, and tools are consequences and should be picked accordingly.
“We should make the system ready for the future”. The future is too uncertain to waste time on big design upfront (and big roadmaps). Why prepare the system for a million clients when you have 10? Don’t future-proof. Focus on the present needs. Do the minimum necessary to accomplish the current goals while leaving options open: the system is ready for change with few lock-ins (e.g., the codebase is lean but easy to evolve). Embrace uncertainty by making change easy rather than by trying to predict the future.
“Requirements must be well specified”. The word requirement is too prescriptive as it precludes that someone is defining and dictating solutions for the team (Taylorism). User stories are just placeholders for user problems. The team should be able and trusted to find solutions.
“Adding developers makes the project go faster”. This is a classic myth quite elaborated in the Mythical Man-Month (nine women can’t make a baby in one month). More people means more onboarding, more lines of communication, and more misunderstandings. The best teams I was at were small. On a company level, if WhatsApp scaled to 1 billion users with only 50 engineers, why does your startup need 300 engineers?
“You need a backlog”. A backlog is a place where ideas and promises go to die. All you need is the current stories in progress and a few more ahead. That’s the way to embrace the uncertainty of the world. Being able to steer often is the essence of agile.
“It’s normal to have a steady stream of support tickets.” You may never get there, but you still should fight for a zero-ticket scenario. On one hand, you should fight to solve the root causes rather than take a symptom-oriented approach. Additionally, empowering customers to become more self-sufficient also helps.

Roles

“Teams should be frontend and backend”. When agile fans tout autonomous and multidisciplinary teams, they mean that they have all it takes to put value in users’ hands. Splitting teams by technology makes them dependent on each other and needs lots of alignment, thus generating waste. Also, splitting by backend and frontend means you’re just creating tech stories.
“QA is a separate phase”. QA should not be a separate phase controlled by specific people (that would be as awkward as doing performance tuning in a dedicated phase). Many teams don’t even have QA people, but they have QA. Quality is part of a culture, not an afterthought. If you have a “Ready for test” column on your board, that’s a process smell — you’re doing a biweekly waterfall. QA is a skill and should be ingrained in everything the whole team does — you need automated testing, TDD, proper CI/CD, delivery in small and revertable changes, everyone capable of doing acceptance testing, etc.
“Architects should be a dedicated role”. Architecture is better solved together in teams. Separating planning and execution is Taylorism. Architecture, QA, UX, security, performance, and agile coaching should all be embedded in the team. They’re not to be done upfront or as an afterthought.
“A team needs a boss”. This is what Silicon Valley “gets” about software engineers that traditional companies do not. Teams are made of well-paid grown-ups who should be trusted to do their jobs, which include self-management. Managers can enable, mentor, and unblock.
“A scrum master is like a manager”. I’ve heard about some companies with the false belief they became agile, but all they did was rename managers to Scrum masters. A Scrum Master is not above the team and does not manage the team, the project, or the product. It’s only there to unblock, enable, and coach regarding agility. The team can do that, so a Scrum master is often unnecessary.
“Devs should be protected from the business”. This is the most detrimental myth. The team doesn’t need to be protected from the customers and users because helping is their job. A central figure talking with the customer is a single point of failure. Developers are not coding monkeys and can also help with user research and much more. The development team is part of the business rather than a separate entity.
“Design is a service”. The team should have the autonomy to deliver user value, including design. Therefore, design should not be split away from the team. A design team is a bad idea (it’s like a team of doctors and another of nurses).
“Design is only for designers”. No, it’s not. Design is about solving problems. It’s a team concern (just like QA and security). Check out “Product Design for non-designers” for more details and related myths. By the way, design is much more than making icons; for example, it includes user research.
“DevOps is a job”. DevOps it’s not sysadmin or SRE. DevOps (development and IT operations) is a school of thought. It suggests developers should be empowered to build, deploy, and maintain their apps. You build it, you run it. One DevOps tenet is automation, including the CI/CD practice.
“The team shouldn’t waste time interviewing candidates”. There’s no one in a better spot to interview than who will work daily with the candidate. Team outsiders know little about the team culture and needs. The team should be empowered, trained, and trusted to interview people. That’s not wasting the team’s time; that’s an investment.

Development

“QA means testing everything manually”. The DevOps culture suggests automating all that’s commonly repeated and error-prone. Developers should be writing automated tests since manually testing everything does not scale and is incompatible with continuous delivery. QA-specialized people should be doing exploratory testing instead.
“A unit test is a function test”. No, it’s not. It’s a test of an observable behavior.
“The more tests you have, the better”. The client doesn’t buy tests. They’re fundamental but have costs (e.g., maintenance, test time). Do the minimum tests that provide safety, documentation, problem pinpointing, and refactoring support. If you use TDD, that’s partly ensured (you might need to do some cleanup in some cases). A related misconception is that “100% code coverage” means a great safety net. However, the code can be broken in many ways, and the tests might be painful while refactoring.
“TDD means writing tests first”. TDD is a more incremental and manageable process. You focus on one test (specification) at a time (each test only focuses on one behavior at a time); even better, one assertion at a time. In other words, you do the bare minimum to make a test fail and the bare minimum to make it pass. Do it in an endless loop.
“Company K uses it; therefore, we should have it.” This is one of the most harmful but recurring myths. There are no silver bullets. (e.g., “Monzo has microservices; therefore, we need them”). You don’t have their problems, so don’t bring their solutions. You don’t need microservices. The product is not a playground. If you want to try something, do it as a side experiment. This myth also applies to product features, team tools, and methodology (e.g., “Let’s implement the Spotify model to bring agility”).
“Refactoring is a separate endeavor”. Ron Jeffries says: “If someone thinks refactoring belongs on the backlog, they probably don’t understand refactoring, backlogs, or both”. Refactorings should be done when tackling real user stories (right after or before). You’ll never have more context. Don’t create refactoring stories since they’re tech tasks masked as user stories.
“Sharing code is the best solution to DRY”. Duplication is far cheaper than the wrong abstraction. Sharing code is too overrated — it’s the best way to couple all your features, thereby annihilating modularity. Most of the code that could be shared belongs to the language and open-source libraries already. Also, DRY applies to knowledge, not code.
“Let’s build something generic”. This is one of the top coding fallacies. Generic/flexible solutions remind me of waterfall thinking — over-promising, keeping the users waiting, getting no feedback, and doing the wrong things… So stop building generic stuff and focus on small iterative wins. I’ve seen many UI tables with dozens of filters, but no one’s using them. Adopting a lean approach is not easy — it’s a mental leap, but anyone can do it.
“Language X will bring a huge performance”. For general purposes, any language will do. The performance bottlenecks often lie in wrong architecture decisions (e.g., loading all database rows and abusing inter-service sync communications). Using Go or Elixir won’t fix those decisions. Otherwise, we’d all be coding in Assembly.
“Performance is paramount”. Optimizing code solely for performance can be bad. Other things come into play, like readability, which leads to ease of maintenance and building new stuff. Optimize for performance only if that’s an actual need.
“Microservices are good; monoliths are bad”. This is a highly narrow-minded point of view. If monoliths are properly modularized, they can have most of the microservices benefits without (de)serialization, network latencies, errors, etc. Monoliths are the perfect way to start and, in many cases, continue.
“Code always needs comments”. Code comments can get outdated and ambiguous and are often an excuse to write mediocre code. Comments are not evil per se but should be used as an exception and not a general rule. Aim for self-documenting code, especially in high-level languages.
“Making queries in production databases is normal”. Querying the production database shouldn’t be a thing. Direct access to databases can hinder their performance, make you lose data, or bypass your business domain rules, besides the fear involved. The correct approach is to create proper tools to fulfill those data access needs (e.g., logs, scripts, APIs, GUIs, CLIs).
“CI/CD is a server that runs a pipeline”. CI/CD is a set of practices that enable continuous integration, delivery, and deployment. Besides the necessary tools (including a CI/CD server), it requires supporting practices like trunk-based development or short-lived branches, a strong culture of automated testing, app monitoring, ease of reverting, etc. All this requires a mindset that differs from the norm.

Developers

“A developer needs a CS degree”. Not necessarily. I’ve seen excellent developers without a CS degree. Indeed, CS concepts are fundamental, but that doesn’t mean you can’t learn them along the way with passion and persistence. That passion will influence your daily attitude, willingness to learn, help others, etc.
“A good developer masters the terminal and vi”. This is just masked gatekeeping. Vim, IntelliJ, terminal, GUIs,… are just tools, not barriers to entry. Use whatever makes you happy and productive, and don’t bully others.
“The 10X developer myth”. This developer is the hero/champion archetype who solves hard problems and amuses the managers. When everything floats around one person, you have a bottleneck and a single point of failure. Those developers are also a black hole of knowledge, so they should invest in sharing it and helping others.
“A senior developer is someone with many years in the field”. The split between junior and senior is ambiguous and often unnecessary. Why? Being a senior software developer is not a binary state. You may be doing the wrong things for ten years. You may become good at more things due to more effort. Many juniors can be seniors in specific things, and many seniors can learn many things from juniors.
“A developer is just a coder”. You are not a coding monkey. The amount lines of code should not be used as a measurement of a developer. Coding is a tool and a means to an end. If you can solve user problems without coding, you’re winning.
“A developer works alone”: No! This myth arose from open-source development and the early Silicon Valley startups. In the normal product development world, developers are supposed to work together with other developers and the team. They can also help with user research.