About a month old but still amusing…
Sponsor: Do you build complex software systems? See how NServiceBus makes it easier to design, build, and manage software systems that use message queues to achieve loose coupling. Get started for free.
Depending on your location and the amount of opportunity may ultimately decide which side of the fence your on.
For me, understanding why a tool/framework exists and the problem is solves is much more important than understanding how to use a specific tool/framework.
Anytime the hiring discussion comes up, I am always reminded of this. While do people classify themselves this way in a resume? Django Developer? I guess if you only want to develop in Python using an MVC framework, then sure. But doesn’t this tend to lead to “When all you have is a hammer, everything looks like a nail”.
The understanding of a pattern or practice is transferable between programming languages and frameworks. NHibernate or Entity Framework? StructureMap or Unity? Who cares! You probably won’t touch the delta anyway.
While I was attending Agile & Beyond last year, David J. Anderson did a great keynote on “stop doing agile, start thinking agility”. In that keynote he said something that has stuck with me: Making progress through imperfect information.
There seems to be a stigma with refactoring. It might not be refactoring, but getting it right the first time mentality. We want to create the right solution and fear making the wrong decision because we don’t have all the information we think we need.
Make progress with imperfect information and refactor later when more is known or wait for better information? I believe the best option is to deliver working software earlier. This now leads into Continuous Delivery… maybe a post in the future.
Remember, you can only make a decision based off of the information you have at that moment. Is it possible that you will see a flaw in your decision and have to refactor? Of course, but embrace change!