Familiar Rehashes of Language Critiques
I spent the weekend reading every post on M O. C’s blog, I’m starting to read more about code than write it! Some of it was insightful, although he does grind the same few axes over and over. I often felt like he was parroting other people with similar concerns rather than speaking from his own experiences. His real insights were hidden in his hyperbolic criticisms, he didn’t pull any punches when talking about how 95% of software gets made.
To start, I fundamentally disagree with his politics. His distrustful attitude towards structure and process that makes things easily predictable and repeatable. He seems to miss the importance of communication and good managers (they exist!) when working in large teams. His focus on the tooling, ability, and culture seriously understates the importance of project structure. The product vision and importance of the team as a larger part of the organization has a massive impact on how the software gets ‘put together’. The process of actually making something that works as quickly and as cheaply as possible isn’t something to be derided, it’s the basis for industry that eventually brought us to the information age. He often weaves his political views into his technical topics, and it’s important to separate them.
M O. C clearly has an appreciation for elegant infrastructure, putting innate value in it’s complexity and the ability to manage it. There is a high degree of skill required to build the architectural masterpieces: expressive languages, libraries, subsystems. Those are often the ‘fun’ problems posed in computer science, but I think he misses the problems found in 75% (This is generous) of businesses. Building good business systems can be a much tougher task than building the foundational blocks, because you have to combine these two disparate fields with conceptional models. The complexity then isn’t only computer science complexity, but people, domain, time, and budget complexity. Not everything can be as hot as AI, but it can be much more complicated.
It comes down to how the sausage gets made. These problems have to be solved by people, with what they know, in the time and constraints they have. No one wants to make a big ball of mud, but they happen for very legitimate reasons. People are learning how to not make all the same mistakes of the past, but when things get built there will be old problems mixed with the new. M O. C prides himself as a software craftsman, with an ability that would qualify as art if code were prose. M O. C’s most insightful posts were showing how ugly the sausage really was and hammering all of the ways to end up in bits. He nailed many of the poor justifications for common mistakes and why the world of software works the way it does. It’s great treatise in failure, and even he laments the lack of a better solution.
A common sentiment is that decades from now, people will look upon C++, Java and PHP like we now look upon Fortran, COBOL, and Ada. I’m not convinced the programming models of today will be advanced until the hardware significantly changes. I think there’s a better chance that programmers of the future will be trained in something that looks more like LabView than Haskell. But I guess compared to M O. C that makes me an optimist ;)