Daniel Doubrovkine bio photo

Daniel Doubrovkine

aka dB., CTO at artsy.net, fun at playplay.io, NYC

Email Twitter LinkedIn Github

I love Heroku and we have had great success with it. Yet, today, I find myself releasing heroku-forward, a gem born from frustration, that works around a seemingly simple limitation of the platform - a 60 seconds application boot timeout.

Why did I need to do all that work? How hard can it be for Heroku to raise a timeout limit? The truth is that it’s probably very hard. I don’t know anything about Heroku’s internals, but I bet that there’s some math going on on for resource allocation as well as a system that runs on a 1-minute cycle. Changing a number impacts everything, making some customers happy and others upset, adding risk.

We all make similar design choices that hard-code numbers all the time. I’ve deliberately created a 1:1 relationship between an object and the object’s owner knowing that in some future an object may have multiple owners. I’ve probably saved countless hours of minor pain doing so, but I am about to pay the full price. The entire system must be turned on its head.

Are those two issues comparable? The biggest difference is control. In the Heroku PaaS example, someone else has it. In my domain model, it’s me. But after years of tinkering with every single layer of hardware and software, I find myself increasingly comfortable delegating control of those areas outside of my domain expertise. I guess it’s called focusing exclusively on your core competencies.