I completely agree with the idea that we are overestimating the impact of tools, specifically, programming languages.<p>I often see startups that rewrite their software one or more times just because they think that changing the tools is the key to success. They switch from PHP to Python, then from Python to JavaScript then from JavaScript to Go. It's so easy to say "We failed because X language, now we have to use Y".<p>The case when choosing a given language will give you a considerable advantage over choosing another one is very rare.<p>The worst thing is that we tend to say that languages suck while completely ignoring all the evidence of the opposite. How many times we have heard that PHP, C++ or JavaScript suck? How many amazing software projects have been built using these technologies?<p>On the other hand, look at the tools that self proclaim the best ones (lisp, haskell), how many big complex software projects have been built with them?<p>In the end they're just tools. Yes, they make a difference, but it's tiny compared with all the other pieces of the puzzle of how to build good software.
Writing software is hard but to me the hardest part is always taking a random abstract concept from someone's mind (or worse, several people) and converting that into something "real" in a fixed timeline and budget. There will have to be lots of tradeoffs and miscues by definition. We are always making something that doesn't already exist, it is creation and creation is hard.<p>I do agree that tools (and process and ....) can make it less hard but that requires real, active participation. And I think that is even harder...
In my opinion the biggest reason why writing software is hard is that the requirements are often not clear from the beginning. Changing requirements can kill a software project. What makes it even harder is when data has to be migrated during the process.<p>Analogy for clueless manager types: in many cases, software is 99% plumbing. But imagine the cost of changing the plumbing after the house has been built :) Also consider the problem of changing the plumbing while people are actually living in the house.
Writing software is hard yes, but I disagree with the author: I <i>do</i> blame the tools. Every language since C has been created as a reaction. What I mean by this is:<p>> C++ was created as a reaction to OOP being so difficult to do in C.<p>> Java as a reaction to memory management being difficult.<p>> C# as a reaction to Java not being concise enough.<p>> Javascript as a reaction to HTML not being dynamic enough.<p>> Go has a reaction to parallelism/concurrency being difficult.<p>> Rust as a reaction to what C++ has become.<p>And it goes on. There are many other languages too that you won't hear of that are created as a reaction to the status quo not being good enough either, but those ones I listed were backed by a big enough majority to become known. There is also the Lisp family and the functional paradigm too, which come round again and again in popularity.<p>All these languages/tools are the problem because no one is sitting back, and pro-actively realising that the <i>entirety</i> of these languages are no good. I am not saying this to start an argument, I have happily been a programmer for 15 years. But I recognise the problems, and they are the same problems, that will repeat over and over again ad-infinitum. I actually started writing down problems I've found and possible solutions and it's already reached over 30 pages.<p>What it boils down to is that all languages share the same flaw; they specify the <i>what</i> and the <i>how</i>, but never the <i>why</i>. Until we figure out how to encode the <i>why</i>, we will forever be going in circles.
I'm surprised at how little DHH says here. He could have stopped writing after the fifth paragraph. Or just added the phrase "Don't blame your tools" to the headline. Like bad code, this post is verbose and most of its verbiage redundant. Good writing, like good code, is a long apprenticeship.