Challenging Software Development Assumptions

Sometimes it's a good idea to take a step back and challenge some of the common assumptions we're all led to believe as software developers. Here are a few pieces of advice that go against the normal narrative:

1. Don’t Always Strive for “Clean Code”

Code must always be clean and elegant, right? Well sometimes pragmatic, “ugly” solutions are faster and more effective, especially for prototypes or rapidly changing requirements. Over-architecting can waste time and stifle momentum.

Facebook’s original PHP codebase was famously described as a “big ball of mud.” The team prioritized rapid iteration and user feedback over code elegance, allowing Facebook to scale quickly and dominate its market before later investing in code quality.

2. Avoid Over-Testing

It seems we are always shooting for 100% test coverage without stopping to ask ourselves if all of that code is really worth testing. Sometimes manual testing or targeted, high-value tests are more efficient than exhaustive automated tests, which can bloat the codebase and slow down development.

Startups like Dropbox initially focused on core functionality and business value, using selective testing and manual QA. Only after finding product-market fit did they invest in comprehensive automated tests, saving time and resources when the product was still evolving rapidly.

3. Don’t Blindly Follow Agile

Agile isn’t a panacea. In some environments—especially with well-understood requirements and stable teams—traditional waterfall or hybrid models can outperform Agile. Agile ceremonies and sprints can introduce unnecessary overhead for small teams or simple projects.

NASA’s Mars Rover software was developed using a waterfall-like process with upfront planning and rigorous reviews. This approach worked well because requirements had to be fixed and quality was paramount—showing Agile isn’t always the right fit.

4. Documentation Can Be Overrated

While documentation is important, excessive documentation can quickly become obsolete and a maintenance burden. Sometimes well-written code and good commit messages are sufficient. Focus on what’s truly useful for future maintainers. Please always write a concise clear description of your class and any other code that may help a future developer and maintainer.

Many open-source projects (e.g., Redis in its early days) had minimal documentation but very readable code and clear commit messages. The lack of heavy documentation didn’t prevent adoption; instead, the simplicity of the codebase encouraged contributions.

5. Don’t Always Refactor

Refactoring is often praised, but unnecessary refactoring can introduce bugs and waste time. If the code works and isn’t causing problems, sometimes it’s better to leave it alone. Don't fix what isn't broken.

Twitter’s early Ruby on Rails codebase was left largely as-is during explosive growth phases. The team focused on scaling and delivering features, refactoring only when absolutely necessary. Over-refactoring could have slowed their ability to respond to market needs.

6. Ignore Trends

It’s tempting to jump on new languages, frameworks, or methodologies, but established tools that “just work” are often better choices. The shiny new thing isn’t always the right solution for your team or project.

Basecamp (formerly 37signals) famously resisted adopting JavaScript-heavy frontends and microservices for years, sticking with Ruby on Rails monoliths. Their products remained stable and maintainable while many competitors struggled with the complexity of trendy stacks.

7. Don’t Optimize Prematurely, But Don’t Ignore Performance Either

The advice “don’t optimize prematurely” is useful, but ignoring performance concerns can lead to problems later. If you know you’ll need to scale, it’s worth considering performance from the beginning, at least in your architectural decisions. Just make sure your optimization decisions are based on sound data.

Amazon’s early architecture was designed with scaling in mind, even before they needed it. This foresight allowed them to handle massive growth with fewer rewrites, avoiding the pitfalls of pure “build now, optimize later” thinking.

8. Embrace Technical Debt—Strategically

Technical debt isn’t always bad; it can be a tool for rapid iteration and learning. The key is to manage it consciously and pay it down when the time is right.

Instagram initially built its backend on Django with hacks and shortcuts to ship fast. They consciously took on technical debt, knowing they’d pay it down after validating their product. Once acquired by Facebook, they re-architected for scale.

9. Not Every Developer Needs to Be a “Full Stack”

There’s pressure to be proficient in everything, but specialization leads to deeper expertise and better results. Not everyone needs to know frontend, backend, DevOps, and security. As one developer put it, "I can do anything - I just can't do everything"

At Google, there are engineers who specialize deeply in areas like search algorithms, infrastructure, or machine learning. Rather than expecting everyone to know everything, Google builds strong teams from diverse specialists.

10. Communication Can Be Overemphasized

“Soft skills” are important, but not every developer needs to be a great communicator. Sometimes, deep focus and technical excellence are more valuable than constant meetings and collaboration.

Linus Torvalds, creator of Linux, is not known for his diplomacy. His technical brilliance and focused vision drove Linux’s success, even if his communication style wasn’t always collaborative or soft-spoken.