Coding Best Practices - Really?

I tend to start with a disclaimer for similar topics, but not in this case. I have seen so many developers have such a dogmatic approach to "coding best practices" that the lack of innovation, open-mindedness, and just plain arrogance baffles me.

When I was a junior developer, I wrote code to solve the problem. I didn't care what the problem was, I was going to solve it. Brute force tactics. I won. I solved a lot of problems. I also created a lot. I learned that I may, in rare cases, have to revisit my code because it wasn't perfect the first time I wrote it. I know, shocking right? Craziness.

When I became developer, I considered more scenarios, tested better, and even thought of how a user, who is not a developer, may use the feature or product I was building. Notice, I considered it. I didn't always implement against those considerations, but I was starting to think about it.

When I became a senior developer, I simply felt older. My old practices became my "best practices" because they worked for this long, and I'm a senior developer. I trudged a long following what I thought was best practices because they worked for me for a while.

Now I have been a development manager, director of development, and currently head of engineering, and what have I learned now? That best practices are not the same best practices as they were 20 years ago, or even 5. Best practices change with new technologies and new solutions to old problems. IE page transitions were an amazing technology when they came out until someone realized that they took 100% of a computer's cpu to do that... then came JavaScript transitions to do the same effect with a lot less cpu.... now we use CSS animations...

Another good example is design patterns. Singleton, Factory, Decorator, MVC (which isn't new folks, people are just getting on board... MVC, MVVM, MV(something else)... etc... I love design patterns, especially when explaining code to another developer. However, you don't need to implement a factory pattern to generate dynamic html on a STATIC PAGE! It is NOT DYNAMIC, so why bother implementing it? I heard in a podcast recently, I think it was a .Net Rocks one, people need to get off of their high horses and do what is right.

It is not the best practice to create unit tests that give you 100% code coverage for a static html page.

That is just silly. I could spend hours developing my perfect powershell script that incorporates grunt tasks for minification and bundling, with jasmine unit tests around my alert box that says 'hello world', with a flawless continuous deployment strategy based on the unit test success to expedite software delivery. Or, I could open notepad, write a simple html page, and ask the user if that is what they wanted.

Now, here comes a minor disclaimer.. SOLID principles are important in everything you do, especially the S. Design patterns are valuable depending on the type of application or site you are creating. If you are creating a new enterprise framework that the entire company is going to leverage and potentially be used by third-party developers, then you better create great documentation, amazing unit tests, and be able to explain every line of code that you created and why you made those decisions. On the other hand, if you are creating a blog for your nephew, fire up some WordPress theme and off you go.

Here are a few rules I try to follow (now)

Know your audience.

What do they actually want? Do they know what they want? What problem do they have that you are actually solving? Yes, actually, not perceived you are solving because you are trying to make money off of them. In some cases, you may not need to solve anything and they don't need you. But until you know what they want, you can't know what you need to do.

Less is more

You don't need a bunch of amazing redundant systems and multi-tier architecture to support a friend's site about his dog. The simpler your code is to explain, the more stable it will be in the future. Here is a quote to live by: "Complexity builds instability". Simple code decreases the learning curve for new developers, increases the stability, and makes it easier to test (in some cases, yes I know concrete classes lead to integration tests not unit tests, blah, blah, but you get my point).

Rubberduck your code

If you have someone to code review with, then great, but at least rubberduck (rubber duck debugging) it. It will help go back to the previous rule (Less is more)

Test your stuff

Testing is critical. Testing could be a simple happy-path test, or over 5000 unit tests, 3000 integration tests, and 8000 UI automation tests. It depends. The phrase that every good software architect loves: "It depends". If you do no testing on your product, then you have failed in every regard as a developer. Even bad developers at least load their application once.

So best practices depends... depends on what is available, depends on what your constraints are, depends on what your experience is, and depends on your product. The argument I often hear is that best practices should apply to all situations. That is not true. Do what is needed, plan for change, and have fun.

Had to vent a little about dogmatic developers. I know I don't know everything. I do know that I keep learning. I also know I try to get better each day.

Thanks for stopping by.