Hacker News new | ask | show | jobs
by angarg12 640 days ago
> even further toward infrastructure, the slower and more thoughtfully you should move. These things often have far less rapidly changing requirements

I used to think that, until I worked on my first large scale system, infra heavy. It turns out it works both ways.

If changing infra is hard, slow, painful and risky, people will be less inclined to do so. If changing infra is fast, easy, and with low risk, people will be much more inclined to change things.

Even if you had very stable requirements (doubtful in this day and age), I see no reason why you wouldn't build your system in a way that is easy and safe to change, for the day when it's needed.

3 comments

You should still ship early and ship off in with infrastructure projects, but the changes you're going to make are going to be a lot smaller, and the big ones are going to be planned far in advance. You will still need big changes, and even your small changes require subjectively "more" thought.

Both things are true: you should move slower and more thoughtfully on infrastructure projects, and "ship often" is still valuable advice and a worthwhile goal

I don’t disagree at all, but I want to be clear that my point is more about upfront thoughtfulness and less about continual ability to iterate.

Being careful upfront often increases your ability to iterate rapidly because you aren’t constantly dealing with the consequences of poor early decisionmaking that causes calcification.

Because you cannot build a substantial system such that it is easy and safe to change. Especially for changes you didn't foresee.
Hard disagree. The system I'm talking about is the largest scale system I've worked with (millions of QPS, thousands of servers). We built it in such a way that we were able to rewrite entire parts of our stack easily and relatively safely. The techniques and tools to do it are widely available today.
Good for you. Modular programming goes a long way, of course, but I'd say that your changes were then those that could be foreseen, for example by drawing the right modular boundaries from the start.