Software Profession Myths.

If you’ve been in the software development game for a while, you’ve probably heard things like:

• A hotshot programmer is 10, 50, or even 100 times better than your average Joe.
• The knack for programming is a divine gift, handed out only to a chosen few by the Computer Science gods.
• Test-Driven Development (TDD) allows you to code both faster and better.
• Counting lines of code as a measure of complexity is a waste of time.

Surprisingly, none of these commonly held beliefs stand up to reality.

This isn’t exactly shocking. After all, even though we use logic in our daily work as software professionals, we’re still human and susceptible to myths and fallacies. What is surprising, though, is how much of our industry mythos is built on these shaky foundations instead of a fact-based approach.

Recently, I stumbled upon an eye-opening video by Greg Wilson titled “Software Engineering’s Greatest Hits” that debunks many of the common misconceptions.

As astonished as you are (or will be after watching the video and slides), I’ve compiled a list of findings from some of the papers mentioned in the video just to jumpstart a fact-based ground truths of software development.

Learning the ropes

• Languages in the C family are as hard for novices to learn to read as a randomly-designed language (sic!). Ruby and Python are significantly easier¹.
• Quorum - the language deliberately invented as easy to learn by novices is still easier¹.
• The most common actual errors made by novices are: mismatched parentheses, invoking methods with the wrong arguments, reaching the end of a non-void method without return².
• Problems that are hardest to fix by novices: confusing short-circuit logical and bitwise operators, comparing strings in Java (.equals vs ==), ignoring the return value from a non-void method².
• Teaching people design patterns makes them better programmers (cause-effect)³.
• The major benefit of pair programming is the transfer of problem-specific knowledge⁴.

TDD

• No significant difference was discovered between test-first and test-last development⁵.
• The claimed benefits of TDD may rather be due to the fact that it encourages fine-grained steady steps that improve focus and flow⁵.

Error Handling

• Turns out, that no measure we currently have is better in predicting effort or error rates than counting lines of code :) ⁶ BTW here I can suggest cloc  script as a go-to tool for that purpose.
• Research shows, that in most cases we wrongly handle exceptions in code is log the or ignore⁷.
• When a developer fixes his own mistake, very often tend to fix or change other things in the same pull request - what makes it harder to pin down the original fix⁸.

Productivity

• There is no a ‘geek gene’⁹.
• It is safe to say that the best programmers can be 3.7x times better than the median of developers (using the same programming language)¹⁰.
• Developers tend to create a lot more configuration options than users use :)¹¹
• The use of code review bots increases the number of merged PRs BUT decreases inter-programmer communication¹².
• Hackathon projects are useless, most of them are dead after the deadline¹³.