For a start, it's not the lean/agile way to have a large capital cost for your idea. If the idea dies, so does all that money you've wasted.
Secondly, the example given is quite naive in design. You wouldn't serve directly from s3 because of costs so you would serve via caches/cdn; for instance, using aws cdn would cost 85 cents.
Going back to the first point though, you're putting a lot of money at risk.
The problem facing these tools is a catch-22 really - diagrams are useful when understanding big messy codebases but big messy codebases are hard to visualise.
For instance, I frequently build small paper diagrams of different code paths through a component and nearly always find leaky abstractions, mixed layers of abstractions, weird cyclical dependencies, etc. etc. and there really is no clear way to diagram this. Instead, you sort of have to make judgements and assumptions to make the diagram concise and understandable; the sort of decisions that machines just aren't that good at.
On the other side, when code is simple and easy to follow then the pay off of building a diagram just isn't there.
Build it the stupid way first is short sighted imo but this might just be an exaggerated way of saying premature optimisation is wasteful.
Just putting it out there, but I think Knuth’s aphorism is being used and abused to the point that some folk believe system qualities are second to functional requirements when it’s not the case.
IMO a lot of teams can do CD but chose not to as they don't have the risk appetite or maybe the resources to handle problems occurred at deployment time. (Tests, however many we have, simply won't cover every scenario that could break a deployment).
SOAs when implemented correctly don’t have any of the issues Michael describes; for one, cascading errors shouldn’t happen and devs should test for this in their game days.
Years ago when I first graduated went to an interview for a Java dev role. Spent the full day there getting pulled apart by whiteboard interviews, exam papers, and daft questions that would have no real day-to-day use in a dev role. Even worse was I asked at the end of the day what kind of work I could be expected to do and found out there was very little actual dev work; maybe some maintenance tasks but mostly support. I became pretty bitter about tech interviews after that.
Sadly interviews like that became a regular fixture and some were even worse. In a few I even had take-home assignments where I was to implement a full-project from scratch then present it at the interview (as well as all that other crummy interview stuff). I even got heavily criticised/insulted in one for prioritising my current job over the assignment and was told if I really wanted the position I "should've moved heaven and earth" - pretty deranged to ask someone to risk their income for an unpaid assignment if you ask me but anyways.
With that being said, I do think interviews are becoming better. They're less about blowing smoke up the interviewers arse and more about judging how good a fit they are for the company. Interviews tend to feel more collaborative and white-boarding sessions aren't a test but a discussion, with the best language agnostic. Hopefully they keep going this way.
I work using R almost everyday and I think many of the problems that are unique to R could be solved by having a couple of experienced SWE in the core team to point R in the right direction. As it stands, I think R will be left behind until it fixes things like performance and scalability (e.g. intuitive byref semantics and a faster runtime) and a consistent scoping model and OOP.
Apart from that, I think there's a bigger challenge which still needs to be addressed is that analysis/modelling projects tend to be worked on by individuals and/or thrown away after the initial value is pulled out of them.
Going forward, I think we need to start identifying design methodologies that would make collaborating on this sort of work pain-free and more agile. Doing so should give us more value and sooner and for longer.