Using A Framework Is Like Getting Married

I read an article on netpoetica that I really liked. It made some really excellent points I want to riff on.

Many times (I’m guilty of this too) when you’re involved in a greenfield project, the discussion is which framework should be used. Often, this comes from which one the team has the most experience using. A great point the article makes is that you should plan thoroughly upfront, and then decide on a framework based on your precise specifications. This is excellent advice but I want to add my spin on it. I absolutely agree, but I would say that the discussion of which framework shouldn’t exist to begin with.

I definitely see the argument that you should build to a spec and not a framework, but I will push back and say that you should pick one framework, two at the absolute most and just master the bejesus out of it. For most of the projects I have been involved with, the functionality is about 80% similar. What do I mean by functionality specifically? I mean things like logging in, user sign up, CRUD operations, etc. There is only about 20% of code that contains logic that is specific to the stakeholders requirements. Now, I’m talking Web App projects. I don’t know if this applies to developing systems for Aircraft or Nuclear Power Plants. One framework I love and fits most of my needs is Ruby on Rails. I know it’s ugly to use the scaffolding and all of that stuff. I won’t debate on best practices, but if you look at it from a business point of view, you can systematize a lot of the development! You would be able to give more accurate estimates for clients, you would be less likely to run into surprises and budget overruns. It’s great! All of the business logic can be wrapped up in its own library that you can then keep separate from the framework. So if you choose Sinatra down the road, it won’t affect any of the business logic.

Something else I want to riff on is what is talked about later on in the article about recruiters liking to see number of years of experience you have with a given framework, library or language. I think this is total and utter garbage. I’ve personally worked with many developers with double digit years of experience who displayed little proficiency in that particular language, not even a framework. That person just so happened to have the same job for about a dozen years doing the same thing. Of course on a resume, that counts as years put in.

The last thing I will hit on is the importance of reading the source code of your chosen framework. It’s all well and good to use a framework regularly, but please take the time to read the source code. To go one step further, I would try to make some contributions to that framework. Even if your submissions get rejected, keep doing it anyways. You gain more from having a deeper understanding of the source code and this will help to mitigate future unforeseen problems. There’s actually a great book that I read that was a huge help for me. The book is Code Reading: The Open Source Perspective by Diomidis Spinellis.

Don Marges

Don Marges

Fullstack Web Developer

comments powered by Disqus
rss facebook twitter github youtube mail spotify instagram linkedin