It’s one of the principles that has guided Facebook’s development process since its earliest days. In five short words it encapsulates a philosophy of rapid development, constant iteration, and the courage to leave the past behind. Of course, some might wonder why you couldn’t just stop at the “move fast” part. The truth is that breaking things is unavoidable.
I’ve spent my life working with devs and ops guys the last two decades. Seeing the paranoia, the anxiety and hearing about the nightmares.
Recently Marco Arment noted that it was scary how little he’d diverged in his ten years as a web developer. I disagree. Looking over the past ten or fifteen years, the scary thing is how much constant change there has been within the role of a Web Developer. Yes, we are still just sending text over HTTP to browsers, but everything else has changed multiple times over.
As we remember from elementary algebra,
ab+ac = a(b+c). This is called factoring. We can break out the common factor a from both terms, so that we only need to mention it once, simplifying the expression and reducing the number of operations needed to compute it.
When coding we talk of refactoring, one of the central themes of which is breaking out code that exists in multiple places, doing essentially the same thing: Don’t repeat yourself! This is also known as the abstraction principle and is about facilitating code reuse.
When you’ve got an idea, and a team, and you’re raring to get started on hacking for a potential startup, a question that often comes up is, “well, what technology should we use?” (hopefully you’ve answered the necessary, “what problem are we solving and how are going to solve it” questions first).
The key issue is balancing newer components that might make you move more quickly, versus tried-and-true components that have more predictable performance and reliability. Here are a few things to consider when picking components: