Why Framework Matters

By Posted September 6th, 2015

(… Especially for lightweight, feature-driven development)

Simple is not always best

Image 1Early on in their careers, programmers learn to always KISS (keep it simple, stupid). But as you delve into large scale applications, you learn that because you didn’t spend an extra hour or two to clean up the code on a feature you created a month ago, it’s now costing you hours (or days) to add one simple change.

Here’s an example. Let’s say you are developing a JavaScript project and your client wants you to create a simple page that shows a list of images and a button that lets you add an image. The simplest and most direct way to do this would be:

  1. Create a view that contains a list control, each item on list is an image, and a button to add image
  2. Create controller that does an Ajax call and after the data loads, populate the list with the images
  3. Add the function to handle the click event of the button and on click, do an Ajax call to add the image

Simple, right? You should be done in less than 4 hours. You pat yourself on the back on how quickly you finished your work. Everyone is happy.

But let’s say your client wants another page that does pretty much the same thing, but instead of images, this page lists documents. You’ll follow the same steps, right?

  1. Create view that contains a list control, each item on list is an document, and a button to add document
  2. Create controller that does an Ajax call and after the data loads, populate the list with the documents
  3. Add the function to handle the click event of the button and on click, do an Ajax call to add the image

Again, you should be done in less than 4 hours. Awesome! You finished two features in one day!

Now what if the next day, the client wants you to make a third page that shows both images and documents on the same page? Super easy, right? Just copy/paste those two pages into the new one and, boom … done! But, wait. What if tomorrow the client wants to change how the images are displayed. Won’t we need to update both the first page and this new page? Wouldn’t it have been better if we created an abstraction while we were creating the first page so that writing this third page would simply require us to inherit a class?

Architecture – plan first then build

There’s a reason why building architects do the designs first before actual construction begins. Building stuff before you have a plan means you’ll likely allocate time and resources on the wrong stuff and you’ll have to redo all of that from scratch later. In software development terms, planning your project’s framework means less time wasted in revisions and refactoring of codes.

Being “lightweight” and “feature driven” means that we push out new features relatively quickly, but how can we do that if we are bogged down following strict framework guidelines? Simple – follow the framework guidelines, but build the foundation of the framework incrementally.

Mock-up is key

If you ask any Web developer that is working with an ERP system how they came up with the design of their new page, and they’ll probably look at you quizzically and say, “I followed the specs, duh!” However, if you ask the very same question to a Web developer working for a start-up, they’ll probably say, “Lots and lots of mock-ups”.

So, why should you create mock-ups and why do it first? Well, you don’t really have to, but I found that it lets you easily segregate your code into data manipulation (Model), UI design (View) and events handling (Control). This is because mock-ups basically have all the UIs in place and possibly several event handling items like button clicks, so all you have left would be data manipulation. Furthermore, you get to see all the UI controls you’ll need beforehand, so it’ll be easier to create abstractions for them (like custom controls). This also helps you in showing your work to your boss or client early on so that you can get feedback on whether you are on the right track or not.

But, that’s no longer simple!

I read a very intuitive blog from Joel Spolsky, CEO of Stack Exchange, regarding one thing programmers must never ever do: rewrite code from scratch. According to Spolsky, the reason why developers love to “bulldoze the place flat and build something grand” is because it’s harder to read code than to write it.

The same principle applies when you look at frameworks. It does seem like a mess, but that doesn’t mean it is. “Why would you create more than three classes just to write a single page,” you ask? It’s because abstracting that class means you’ll be able to re-use it later on the next feature you’ll be working on a few days from now. “Why spend hours reading up on best practices on a framework when I can simply write my own?” It’s because using existing frameworks lets us use all the hard work of those that came before us so that we won’t have to worry about issues that we haven’t thought of.

Results matter. But consistent results matter more.