Getting Back to the Basics: Introduction and Why
In the Java and .NET world today, I am starting to worry we are doing many things just because “that is how you do it.” I think this is a dangerous place to be.
It is a place where education and understanding are trumped by blindly following best practices without really thinking about why or when to apply them.
Not to bash Ruby here, but I think that the recent evacuations from C# and Java to Ruby are in many ways due to this degradation of practicality by so many of the experienced C# and Java developers out there.
I have to admit, I am guilty of it myself. I blindly add interfaces to classes that don’t need them just so I can dependency inject them into my class so that I can write my behavior driven unit tests using a mocking framework.
What am I doing about it?
I thought I would write a series of blog posts with the goal of getting back to the basics. I want to take a thorough look at:
- Why some of todays best practices exist
- What problems they are trying to solve
- What we did before relying on these techniques
- When they are applicable
I want to get back to a point where I am very clear that when I employ one of these best practices:
- I have a good reason for doing so
- It is solving a specific problem
- It has a net benefit
My goal is to take a “nothing is sacred” approach to software development and pick apart anything and everything.
I want to start by looking at some of the basic things like interfaces and ask questions like “why should we even use an interface?”
Honestly, I don’t know where exactly this path will lead, but I am going to take it and see where it goes.
But what about forward progress?
Aren’t all of todays best practices and techniques the result of years of forward progress in the profession of software development?
Yes they are, but that doesn’t mean they are right.
It’s kind of weird how progress works. We end up going down one path for a long time thinking we are making progress until it comes to a dead end, but some of the things we learned along that path allow us to go further on a different path, or open up completely new paths altogether.
It is only in developing solutions to problems that we find other problems that are caused by those solutions, which in turn cause us to go back and resolve the original problems in a different way armed with this new knowledge.
Want a good example of this?
The language itself has not changed, but how we use it has changed completely.
My only point in saying this is to open up your mind to the possibility that things we think are completely necessary today, like unit testing for example, may not end up even being considered valuable at all in the future.
Why is this important?
It is good to shake up your beliefs and questions them every once in a while.
Any belief you hold true should be able to hold up to solid reasoning. It is important to test our own beliefs every once in a while to make sure they are still valid.
Testing our beliefs can help us gain more confidence in the ones that are correct, and stop hanging on to those that are wrong.