There exists many well-known coding practices established to improve the overall quality of code such as test-driven development, frequent commenting and documentation, and structure clean architecture and design. It would be ideal for all code and programs to implement best practices but it doesn't happen, not even in the professional world; why is that? Why can't the industry leaders always implement the ideals they preach? Why do a lot of programs have poor documentation and nearly no unit tests? I believe there's no true answers to these questions but I do have a few points that may explain the lack of best coding practices.
I believe the reason most junior developers such as myself and even many senior developers fail to implement best coding practices is because we program out of passion which tends to lack structure. We tend to build projects from very abstract wireframes and dive right into coding without establishing tests or class structures. We all know this is inherently going to build technical debt and eventually bite us in the future but our unrestricted coding passion only lasts for short periods of time so we take advantage of it. Once the coding montage has settled down, this results in programming burnout where you've run out of motivation to work on the project so you're now left with a rudimentary mess of spaghetti code. The envisioned idea just becomes another folder in the pile of "unfinished projects I'll eventually work on". Maybe we can somehow redirect our coding fits to designing architecture rather than spitting out comment-less, happy-path spaghetti code.
Time is also another issue many developers seem to have. Even though test-driven development and designing program architecture will save time in the long run, it seems to be a waste of time in the immediate sense. Even writing simple comments seems to be a distraction to many of my colleagues. They also dread drawing UML diagrams and more so writing test cases even though they know the benefits of planning before implementing. Maybe it's an inherent problem with programming since ideas are so easily forgotten so we strive to write them down as soon as possible. The ideas are usually so convoluted that documentation and concise design structure become mere afterthoughts. This may also be the source of the lingering sense of urgency even when there's no deadline.
Best coding practices are great in theory but they always seems to be half-implemented in real applications. Let's look at an example: my Spring 2016 project, Ctrl-Cloud, and see how Team Ctrl-Cloud and I failed to implement good coding practices.
Team Ctrl-Cloud was given from January - April to implement a self-initiated project. Our development problems started right from the beginning; we never established a concrete design. Throughout the 4 months, we had little to no documentation, no UML/ER diagrams, and one abstract wireframe.
In the end, we weren't even able to implement the wireframe because we lacked the design foundation. Without a well-design entity-relationship diagram to implement the database, we were at a loss on how to retrieve and set variables let alone implement the frontend that is the wireframe.
Our backend relied on Ruby on Rails which should inherently be easy to implement test-driven development, right? Even with four developers who know how to implement TDD, we lazily decided to dive straight into coding with no clear goal. I think the reason we decided to forgo TDD was maybe we thought the project was too simplistic to need such structure. We realized our mistake but we were too deep into the timeline to refactor the existing spaghetti code.
There existed no coding conventions between Ctrl-Cloud's Java, JavaScript, HTML/CSS, and C#. The reason this happened was clearly because there was no initial documentation and each developer went their separate to implement the JSON parsers. There were also no comments nor documentation in any of our code between the extensions, apps, or website.
Maybe the reason the first iteration of Ctrl-Cloud failed was because it was merely a school project and no one on the team had true motivation to work on it. Another signification reason that may have contributed is we lacked a concrete timeline or implementation methodology; the team had learned about agile extensively but we never sought to use our knowledge. I may personally return to Ctrl-Cloud and release a version 2 with actual documentation so I can release a refactored readable, open-source service.