MonolithFirst
This fits in very neatly with Casey Muratori's "Compression Oriented Programming" which is essentially Write your usage code first, keep YAGNI in mind, then Refactor.<p>I was once asked in an interview whether, on a new project, I would start with a monolithic app or some sort of SOA. ("Microservices Architecture" is the new SOA)<p>I answered that I would start with a monolith because usually you're trying to find product/market fit as quickly as possible, and having an SOA would likely slow you down due to its upfront cost. (How many services? Any redundancy? What do they do? How many databases? How do you keep them up? How do you diagnose when they're failing? etc)<p>They responded that they always do SOA, that the benefits are clear, that monolithic apps are idiotic, etc.<p>I didn't want the job... but I was confused about our differing opinions.<p>What I've learned since then is basically: are you constructing a building, or making an art installation?<p>Construction is thousands of years old. Contractors have huge tables of how long each part of the process takes, in what order, down to the quarter-hour (in some cases) and are fairly accurate in their estimations. (They're still hilariously wrong on occasion either in time or budget, building <i>anything</i> is pretty difficult)<p>In this case, architecting SOA would work out since you've done it before. You know about how long it takes, what the pitfalls are, what support infrastructure you need, etc.<p>When you're making art, making something new, with new materials, without a manual, with only some best practices in mind, time becomes essentially unbounded.<p>Upfront architecture in this case would be poorly suited to the situation - you'll probably end up changing it a lot, and each time you introduce a bit of "rigor" to the system it becomes a bit more difficult to change. Especially over socket boundaries and different API versions.<p>I also feel like bad code has a survivorship bias - you only hear about it because the company took off. To get the company to take off, the code perhaps was necessarily rushed just so the company could stay around long enough to make money.<p>"Ah, but if we could have done it right in the first place!"<p>You don't hear about the companies who die, no matter the quality of their code.