The Biggest Myths Some Software Developers Believe

What are some popular myths in software development? Why are they myths, and how did they become popular? Some of these are myths because they were once true, other because they are convenient distortions in order to promote an agenda, and some because they are naive over-simplifications. Do you agree with these opinions?

#1. I don't need to write comments, my code is self-documenting

Glyn Williams, Game Developer, CTO at Binary Planets Ltd (Crewe, Cheshire, England):

I find myself writing comments in order add more detail and improve things. I imagine my future-self looking at the code, and being puzzled.  So I mainly write comments to assist my future self. 

• Worst. Complex, opaque code without comments.
• Better. Complex, opaque code with comments (most real world programmers live here).
• Better. Simple, transparent code with comments.

• Best. Code so hygenic that comments are utterly un-necessary.

  ‘You should use comments. Because most of us live in the first three categories. The fourth is aspirational.’

• Use comments when the intention of the code is not obvious.
• Use comments when how the execution proceeds is not obvious.
• Use comments when the context of when to call a method is not obvious.
• And not just short little crappy one-line comments either.  Some of this stuff needs a paragraph of well-written English prose to describe.

#2. This code I'm inheriting is crap. I'll have to write it from scratch

Vladimir Ilievski, Artificial Intelligence Intern at Philip Morris International  (Lausanne Area, Switzerland):

"This is the best comment in source code that I have ever encountered".

#3. This is just a temporary hack - I'll come back and fix it later

John Miller, Engineering manager at Microsoft (Greater Seattle Area, Washington):

"You’ll never ‘fix it later’ so do it right. The mistake I’ve made many times is throwing something together with the intention of fixing it before I ship. Then one fire after another springs up, and the code ships in hideous shape. Write it the right way the first time".

#4. Slow is bad (premature optimization is right)

Robert Zubek, Game Developer, Founder at SomaSim (Greater Chicago Area, Illinois):

"1. Optimization reduces flexibility. It's one of the classic tradeoffs of computer science: you can usually buy more speed by sacrificing space (memory, cache, etc) or generality (more task-specific system, etc). So it's a bad idea to do it too early, when you don't yet know which parts of the codebase need to remain general and extensible, and which can be hard-wired for specific use cases.

2. Optimization should be based on evidence, not speculation. In many non-trivial systems, you won't know which parts need the most speed-up, until you have a system running live in a production environment, under a real-world load. Especially when this is a novel system that you haven't built before, it's easy to make incorrect assumptions about what needs optimizing.

‘And this ties to the previous point - if you optimize for the wrong thing, you not only spent valuable time, but you also needlessly reduced future flexibility and extensibility.’

#5. I will be great programmer if I create great code

Mike Coutermarsh, Software Engineer at Product Hunt (San Francisco, California):

"Whether you solve a problem with a thousand lines of C or five lines of Ruby doesn’t really matter. As developers, we place a lot of value in how good we are at writing code. But that’s only a small piece of the puzzle. Your programming skills are very important. But all that time you spend on becoming a good developer can be magnified if you also learn how to create business value with your skills.

A lot of developers keep to themselves or stay secluded in the “engineering cave”. This limits your perspective.

For the first couple years of my career, I spent all my time at my desk coding. If I had to talk to someone in the business, I primarily used email. I seldomly talked to them in person or even picked up the phone. I ate lunch at my desk, just so I could write more code.

I thought I was doing great work. But in reality I wasn’t. My performance reviews were average and other developers were getting put on the best projects. Even though I was writing a lot of “great” code, my work wasn’t creating much value for the business. I spent too much time on small technical details instead of the big picture.

‘I was lucky to learn this from a mentor super early in my career: “Learn how to solve problems that make companies a lot of money”.  Once I started spending time with Product, Marketing & Finance, my career began to take off as a developer.’

So, what’s the best way to be a great programmer?

• Get outside of the “engineering cave” and learn how business works.
• 80–20 rule is everything! Remember, you’re aiming for the biggest impact, with the least effort
• Leverage your technical skills to solve problems that provide huge value".

#6. Agile is a bullshit that does not work

Brian Knapp, Senior Software Engineer at Procore Technologies (Carpinteria, CA):

"Agile is about responding quickly to change. Actually I can write that better: "Agile is about contextual change". That is to say, the purpose of agile is to change quickly to meet the current context you are working in. That can be the market you are in and the demands of your customers. It also means you must change to effectively use the resources at your disposal.

In a truly agile world, nothing is sacred. You do what makes the most sense in your context to achieve whatever the goal is. You can never get to a perfect system. You can only change and get better within your context".  

James Grenning, Software Consultant, one of the original authors of the Agile Manifesto:

"Engineers! With Agile the delivery cycle is fundamentally changed. Have you changed how you develop software? Are you a senior developer, programming the same way you did that first year out of school? Do you have 10 years experience, repeating the same Debug Later Cycle? Have you read any books on iterative development, Test-Driven Development, and Extreme Programming, Design? Have you read any books on development at all? Alas, few hands are raised. The cadence of delivery is changed, so must your practices change.

Why is there so much pressure in your two week iterations? “The stories we are told to do are so huge there is no way to get the work done with any quality. The PO says they are priority one. We have to do what the PO says, right? No documentation; no thought; just do it! That’s Agile! Right?” No, that’s not Agile, but that is a demoralizing way to work. 

FURTHER READING

The way to get startup ideas is not to try to think of startup ideas. It's to look for problems, preferably problems you have yourself. Solving the problem that frustrates you - may be one of the best ways of finding an idea for your startup. Look at these software developers who acted accordingly before they found success.