This essay is excellent, and to me it clearly highlights the difference between an experienced architect that has been there, done that, and got the battle-scar

This essay is excellent, and to me it clearly highlights the difference between an experienced architect that has been there, done that, and got the battle-scars, and those that have not. The attitudes and behaviours Lawrence describes are depressingly common in the industry - where the bandwagon is the most common form of transport - to the detriment of us all. I recently interviewed a candidate. When discussing languages in use, I mentioned a language this person probably didn't like all that much, or didn't have that much proficiency in. His comment wasn't "why did you chose to use that" or something along those lines, but "when are you getting rid of it". The interview came to a close pretty quickly after that. There was little interest in why these choices were made, or why perhaps that language was deemed to be the best tool for that particular job. I really wish this was an outlier, but it is the prevalent attitude. Every day I work with developers that have little regard as to what tool is the best for the job at hand, and approach problems with the idea of "Well, I have this hammer here, and I really know how to use it well, I'm pretty sure I can ram this screw into the board with it" and subsequently proceed on a mission to convince everyone that the hammer is the only tool worth considering. I suspect that the deeper issue is one of either supreme overconfidence and arrogance, or masks a deep insecurity. Whichever one it is, the issue remains. I have had devs insist that "docker is the only way in which can deploy my app, we need Docker RIGHT NOW". Container orchestration is being deployed at $work and we have published a set of guidelines to make sure that developers have an idea on how to ensure their apps will function properly in this environment - it is much along the lines of 12-factor apps, with some tweaks. The pushback I have received from some is that "with docker it shouldn't matter, and whatever I do on my PC you can just pick up and drop in place", with a complete lack of regard for the fact that their PC is not that same as our production environment. After discussion it becomes clear that this is rooted in a combination of ignorance ("I don't know how to do that") and laziness ("I made this app, it works on my PC, it is not my problem anymore"). Doing battle with the tech-fashionistas is a regular thing. No, we are not going to re-write all out applications in C# because we have an intern that can only use C# (an actual discussion). No, we cannot randomly deploy everything on Docker because that is the current hype du-jour. An now, we are not going to back up Petabytes of data to the cloud because everyone is doing it - laugh all you want about tape, but it more cost effective, fits our use-case better, and is orders of magnitude more cost-effective. One of the things that Lawrence mentions really resonates with me: "The guiding rule should be “What is the simplest way to do what we need to do?” If the older technology gets the job done, and is the simpler approach, then it should be preferred. But if there is a new technology that allows us to simplify our systems, then we should use the new technology." I wish we could all get behind that....