| > customers are not paying for, nor give a shit about, these things. Yes, but they do give a shit if: - your product is slow, so they assume it's crap and leave your site - your product breaks, no one notices or fixes it - your product is bad, because your wrote it in a safe boring technology like cobol and therefore couldn't access the best developers. (exaggeration, but variations on this are true) My point isn't that you must use the newest shiniest tech and infra to do everything, my point is that when people write blog posts like this, they want to make it seem like there's a clear line between what's "cool shiny tech" and what's "hard nosed business focused shipping". In reality, it's a lot fuzzier and these things feed back into each other. For example, you shipped bad code early on to get velocity, but it turned out to be foundational and hard to replace, so your best developers leave as your codebase becomes a ball of mud that it's become clear will never be fixed. So now your worst developers are working on a ball of mud and making it worse... etc etc. As always, the answer is that this stuff is hard, and you can't make a technology decision by just considering things a user wants to buy and saying everything else is navel gazing and messing around. |
Yes, those things are always important (if not critical); it's not meant as a defense of bad architecture, merely to try to make those decisions through a product/customers-first lens.
(I did try to connect quality/reliablity, perhaps unsuccessfully, later in the post, e.g. in goals: "If the system is unreliable, we won’t ship as much product ... If we don’t replace this system, more and more customers will experience a broken product.")