22 Dec 2012
Software development happens in various scales, right from little applications, hacks and tools that help us do one thing really well to monolithic operating systems, virtual machines and distributed systems that are managed by large teams of engineers. Having worked in most parts of this spectrum, whenever I have to pick a new language or framework, I ask myself at what scale the project I intend to take on is going to operate in the near future.
By now, most people tuned-in to the lean start-up bandwagon already know about the importance of hitting the market first, iterating quickly on a product and so on. If you’re building something for just testing the waters, it really does not matter if your tech stack cannot scale beyond 100 concurrent users. It also does not matter if you don’t test-drive your application, or if you borrow a free theme or use Twitter bootstrap (still beats enterprise software by miles). Scaling problems might eventually plague you in the future, but from experience, that’s often a happier place to be than convincing folks to fork out their cash for something that they don’t need.
Whenever someone writes a rant about a technology that they are having pains with (hello MongoDB), I pause to ask myself whether the author is trying to use a knife to chop a tree, as more often that not, most rants expect something to be fast, simple, elegant, horizontally & vertically scalable and also help them paint rainbows in Sahara desert. In reality, that doesn’t work, and a lot of people do know it. Yet, somewhere along the way, we get so vested in our tools that we expect it to dynamically grow with our application needs.