Hacker News Reader

Comment by robbiea | Hacker News Reader

IMO, build with what you know already. If you want to build an MVP fast, then use PHP. You can always rebuild to scale later. That's if you NEED to scale, and people actually like your product.

The other argument is, maybe this is a good time for them to learn these new tools. Serious Question: Why are you going to die of annoyance if you are the product guy? As long as they can do what you want it to do, what's the issue?

View on HN

Rebuilding to scale is a bad idea IMHO. The moment your app takes of you have just about everything on your mind, but not a clean slate rewrite in a different language. You'll need to scale and scale fast. So you'll be tacking on hot-fixes for stuff that breaks, features your customers want, ... And the more code you write, the less attractive it sounds to rewrite.

I wouldn't try to convince the coders to use a language that they don't know but I'd really try to convince them to have a look at stuff outside their comfort zone. There's a lot to loose but also a ton of things to gain. Have a look at other storage options (NoSQL, ...), other languages and what benefits they offer. Think of running on environments such as GAE or Heroku that are not available for PHP. They do offer their own share of advantages when it comes to scaling an app. They do have some disadvantages as well. Maybe there's a set of libraries in a given language that helps you a long way, maybe there's not.

However, in the end I'd say that the language you choose is the least of your problems. Cool technology can be built in pretty much any language.

I'd say the happy medium is a SOA design. If you separate out the critical modules into a separate service, a rebuild to scale isn't much more than a refactor to scale, which you are going to have to do at some point in time no matter what platform you build on.

Yes, sure. There's more benefits to reap: You can intermingle your services with services bought/rented somewhere and eventually replace the ones you're using if it pays of at the scale you reached (think redis2go vs. a self-hosted redis server) Services usually offer good boundaries at which you can separate the system and scale over multiple machines as well as a good entry point for black box testing.

As a programmer myself, I would actually prefer starting clean slate with something new (especially for a brand new project), like ruby, nodeJS. Of course, you can stay in your comfort zone with what you know (be it PHP or even .Net MVC C#), but in the long run, the cost of re-writing logic, pain of scale and transition to another platform is truly a buzz kill. I would rather get the code on the right platform first, so that future maintenance is not merely throwing money down in the drain. Not sure about you, but re-writing sounds pretty lame and low efficiency to me.

How do you assess the "rightness" of the platform before you even know the order of magnitude of, say, traffic or concurrent users?

I would love to rewrite my engine if it means I have a thousand times more customers than when I started. I mean, it's a win-win bet I'm willing to take: win now because I know the tools by heart, win later because I'll be making a ton of money later on and I'll be reingeneering a system I know by heart - which is so much cooler than writing fibonaccis in a language I don't know.

Chances are you're going to rewrite it all anyway for a strategic pivot, so why bother now with problems that you don't even know will ever exist? Just pick your best tool and make the most of it - premature optimization is also a form of procrastination.

Reply on news.ycombinator.com