1. Worst practices are viral for the wrong reasons
2. This short post describes my hypothesis for why poor software engineering practices are more viral. Simply stated:
3.  
4. Worst practices spread more quickly because they require more attention
5.  
6. The following two sections outline specific manifestations of this problem and how they promote the dissemination of worst practices.
7.  
8. Management
9. Corollary 1: Teams with the greatest technical debt mentor the most employees.
10.  
11. Scenario 1: You manage a team that ships an important feature but with a poor execution. You can make a compelling case to management that your team needs more head count to continue supporting this feature. More employees reporting to you increases your chances of promotion and you enjoy rewarding opportunities to mentor new software engineers in your specific brand of programming.
12.  
13. Scenario 2: You manage a team that ships an important feature in the exact same amount of time but with an amazing execution. Your code requires little maintenance, so little in fact that your team is now obsolete. If you're lucky you are retasked to work on a new project; if you're unlucky you are fired because your skills are no longer relevant. Training others how to write software of excellent quality is out of the question either way.
14.  
15. In other words, software engineers that produce excellent code cannot easily pass on their wisdom to the next generation of programmers unless they go into academia.
16.  
17. Open source projects
18. Corollary 2: Poorly implemented libraries or programming languages generate more buzz.
19.  
20. Scenario 1: You write a useful library or programming language, but it is incredibly buggy and problematic. This generates several scathing blog posts criticizing your work, prompting others to clarify in response how to work around those issues. Don't forget to check Stack Overflow, which is full of people asking for help regarding how to use your project. Did you know that people measure popularity in terms of Stack Overflow questions?
21.  
22. Scenario 2: You release a useful library or programming language at the same time, except that through some miracle you get it correct on the first try. Version 1.0 is your first and last release. That means you can't advertise your library through announcement posts for subsequent releases and there are only so many ways that you can say "it works" before people accuse you of shameless advertising.
23.  
24. In other words, well-written open source projects can become victims of their own success, with fewer opportunities to market themselves.
25.  
26. Conclusion
27. Obviously the above examples are exaggerated hyperboles and reality is somewhere in the middle. There is no perfect software project or team and there is a limit to how much crap a company or user will tolerate.
28.  
29. However, I write this because I value simple and understandable software and I want to start a discussion on how software engineering can culturally reward correctness and reliability. We need to think of ways to encourage programming excellence to spread.