Thomas Fuchs
Hi, I'm Thomas Fuchs. I'm the author of Zepto.js, of, and I'm a Ruby on Rails core alumnus. With Amy Hoy I'm building cheerful software, like Noko Time Tracking and Every Time Zone and write books like
   Want me to speak at your conference? Contact me!

Why frameworks don’t have much to do with how easy it is to add a feature

November 18th, 2013

You’re using the hottest and hippest new framework? You generate Node-powered Erlang templates in a crowdsourced Haskell cluster? You run JavaScript on a Ruby VM that uses a Lisp DSL? You stream events to your MVVC like there’s no tomorrow?


Whatever you do, in a real business, all of these things are unlikely to help you to launch features faster.

Adding a new feature encompasses a lot more than just sitting down and writing some code:

  • First you need to figure out what the feature is…
  • …then you need to make sure you define what it isn’t.
  • You need to make sure that it will make your customers awesomer.
  • You need to think long and hard about if it’s a good fit for your product.
  • You need to design how it works, in detail. (Don’t forget those pesky edge cases!)
  • You might need to research if it’s technologically feasible.
  • You need to decide if it’s worth the maintenance and support cost.
  • If it needs a user interface, you need to design that as well.
  • You want it to work on phones as well, right?
  • You need to write tests to make sure it doesn’t break anything else.
  • You might need to deploy it in off-hours to minimize disruption to customers. Everybody on the team loves to stay up all night!
  • You may need to adapt your infrastructure and add new hardware and software, which needs to be bought or rented, managed and monitored.
  • You need to write new documentation. (Hopefully not in multiple languages.)
  • You need to update your marketing.
  • You might need to update your onboarding process.
  • You need to tell your customers about the feature, and not just once.
  • You might want to add a tutorial for the new feature.
  • You need to track adoption of the feature and spend time to decide if you need to change anything. If you do, you might have to run through all of the previous bullet points again.
  • The feature might will make future features more complex.

The gist is that programming and technological choices really only play a minor part in all of this. Our old friend, the 80/20 rule applies here: It’s 80% all of the above stuff and 20% implementation.

IMHO, the real strength of a good framework lies in how easy it is to support an application in the long run. I suggest that your choice of technology is based on how you can minimize friction and extra work, as well as how likely it is that it is still around a few years form now.

For web applications, choose something that has good defaults, is easy to test and is playing to the strength of servers (DB queries, HTML generation) and clients (showing HTML, UI interactivity) and minimizes the amount of code you have to write.

For any sort of application, always, always go for something that the people creating and maintaining it use in their own, paid-for products. Avoid anything that solves “potential problems” that aren’t actual real problems like the plague.

Pragmatic, real-world solutions beat oh-so-clean-we’ve-everything-in-layers-hypermedia-blah-blah-blah any day. Personally, my winner clearly is Rails, but YMMV. Heck, I even use PHP in some projects where a larger framework would just get in the way.

But don’t think the latest insert-buzzword-here framework will solve all your woes—it won’t.