The biggest myths in software development
Throughout my work experience, I’ve been seeing a lot of misconceptions about software development that can be harmful to an organization.
Some might be subjective and others might challenge your beliefs, so I hope you keep an open mind. I recommend exploring the links.
- “The more features, the better”. The best tool is not the one with more features; it's the one that better matches users’ needs. Having all features makes your product average to 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”. You probably heard “but it's just a button”. There’s so much more besides the development costs when building a new feature; there are hardware costs, the impact on code maintenance, training to do, and documentation to update, among so many other fixed and variable costs.
- “A product always needs instructions”. The UI should not depend on some user manual to be used and adding instructions is just a band-aid. If you need to explain it, you’re doing it wrong. Try to solve the root issues instead. 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. If your users can’t accomplish some task, 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 that know what the customer wants (product owners, product managers, …). They’re not the authority and don’t have a crystal ball for customer needs. They should team up with user researchers to understand the users. On the other hand, anyone can propose improvements based on their experience with users (e.g. support team).
- “Estimation is useful”. Estimation is generally a waste of time and a source of anxiety. Estimates are usually wrong. People fight over a 1 or a 3 in long energy-draining meetings for nothing. Use that energy to better understand the stories, and to split them into small bits with value. Once they’re small, they’re roughly the same size anyway.
- “Agile/lean is making things quick and dirty”. Agile is not about increasing speed or reducing quality. It’s about reducing the risk by regularly delivering small batches of user value, getting feedback, and iterating on it. Lean is a set of 7 principles which include waste reduction, postponing decisions to the last responsible moment, and team empowerment.
- “Agile is a methodology”. Agile software development is just about our daily approach to problems; it’s user-centered development, empowering teams, delivering small steps, experimentation culture, reducing waste, etc. Some methodologies embody some of its principles (e.g. XP, DevOps, Kanban, Lean) but agile is mostly a frame of mind; not a set of rules in a book.
- “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.
- “Using JIRA is being agile”. Agile is not a tool; it’s a cross-company frame of mind. Start by defining the desired principles, ways of working, and processes. Tools come as a consequence 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. Ideally, you should do the minimum necessary to accomplish the current goals, but leave options open and the whole system ready for change with few lock-ins (e.g. the codebase being lean but easy to evolve). Embrace uncertainty by making change easy.
- “Requirements must be well specified”. The word requirement is too prescriptive as it precludes that someone is defining and dictating solutions for the team. Ideally, user stories are just placeholders for problems. The team should be able and trusted to find solutions. This idea assumes the team follows a user-centered approach having the skills to investigate the stories with the client/users.
- “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 communication lines, 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?
- “Teams should be frontend and backend”. When agile fans tout autonomous and multidisciplinary teams, they mean that the teams have all it takes to put value in users’ hands. Splitting teams by technology makes them depend on each other, and needs lots of alignment, thus generating lots of 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 done solely by different people in a dedicated phase; that would be as awkward as doing performance tuning in a dedicated phase. Many teams don’t even have QA people but they surely 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, always delivery in small and revertable changes, everyone capable of doing acceptance testing, etc.
- “A team needs a boss”. Teams are made of well-paid grown-ups that should be trusted to do their jobs, which include self-management. Managers should be there only to enable, mentor, and unblock. This is what Silicon Valley “gets” about software engineers that traditional companies do not.
- “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 it or the project. It’s only there to unblock, enable, and coach regarding agility.
- “Devs should be protected from the business.” The team doesn’t need to be protected from the customer and users because understanding them is part of their jobs. 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.
- “Design is a service”. The team should have the autonomy to deliver user value and that includes 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 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 that developers should be empowered to build, deploy and maintain their apps. You build it, you run it. One of the DevOps tenets is automation which includes the CI/CD practice.
- “The team shouldn’t waste time interviewing candidates”. Who’s a better interviewer than one who will work daily with the hires? 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.
- “Company K uses it; therefore we should have it”. This is one of the most harmful but recurring myths. There are no tech 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”. As Ron Jeffries puts it, “if someone thinks refactoring belongs on the backlog, they probably don’t understand refactoring, or backlogs, or both”. Refactorings should be part of stories with user value. Don’t create refactoring stories since they’re tech tasks masked as user stories.
- “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 manual testing everything does not scale and it’s not compatible with continuous delivery. QA-specialized people should be doing exploratory testing instead.
- “The more tests you have, the better”. The client doesn’t buy tests. They’re fundamental but they have costs (e.g. maintenance, test time). Do the minimum tests that provide you with safety, documentation, problem pinpointing, and refactoring support. If you use TDD, that’s in part ensured (you might need to do some cleanup in some cases).
- “Sharing code is the best solution to DRY”. Duplication is far cheaper than the wrong abstraction. Sharing is too overrated so stop sharing code. Sharing is the best way to couple all your features thereby annihilating modularity. Most of the code that could be shared belongs to the language library and open-source libraries already.
- “Let’s build something generic”. This is one of the top coding fallacies. Generic solutions remind me of waterfall thinking — keeping the users waiting, getting no feedback, and risking doing the wrong thing, … 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. To be fair, adopting a lean approach is not something easy — it’s a mental leap.
- “Language X will bring a huge performance”. For general purposes, any language will do. Most times, the performance bottlenecks lie in wrong architecture decisions (e.g. loading all database rows, abuse of inter-service sync communications). Using Go or Elixir won’t fix those decisions. Otherwise, we’d be all using 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 requirement.
- “Microservices are good; monoliths are bad”. This is an extremely narrow-minded point of view. If monoliths are properly modularized, they can have most of the microservices advantages, without (de)serialization, network latencies, errors, etc. Monoliths are the perfect way to start, and in many cases, they can remain that way.
- “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 as 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 (with bad queries), 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).
- “A developer needs a CS degree”. Not necessarily. I’ve seen amazing developers without a CS degree. Surely, 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, your willingness to learn, help others, etc.
- “A good developer masters the terminal and vi”. This is just masked gatekeeping. Nano, Vim, Emacs, IntelliJ, terminal, GUIs,… are just tools; not ways of life. 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 commonly amuses the boss. 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 10 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 with “juniors”.
- “A developer is just a coder”. You are not a code 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 arouse 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 as a whole. They can also help with user research.
I hope I was able to challenge some of your beliefs. I’m sure you found exceptions, but the main idea is to make you think about them. Here is some material for further reading:
- Modern Software Engineering (Dave Farley)
- Heuristics for Effective Software Development Organizations (Allen Holub)
- Why your huge tech team isn’t delivering (Roger Nesbitt)
- What Silicon Valley “Gets” about Software Engineers that Traditional Companies Do Not (Gergely Orosz)
- How to go fast (Chris James)