- TOC
{: toc }
I was a bit exhausted from coding last week, so I let myself relax with The Mythical Man Month. I had started it a few weeks ago, but I finished it on Friday.
First of all, it's shocking to see how many key phrases in this field come from this book:
-
The Tar Pit (which is used by the famous "out of the tar pit" essay)
-
No Silver Bullet
-
The Mythical Man Month
-
Essential vs Accidental complexity
Much of the book is still relevant today, even though programming has changed a ton since the 60s, and of course many is just hilarious reminders of how much has changed.
As you may expect, the "No Silver Bullet" essay was the most relevant to me, and I LOVED it. Very, very thought provoking.
The premise of the essay is this: there will be no single magical solution that will drastically improve the beast that is programming. Instead there will be a myriad of small incremental improvements that will over time tame the beast.
A wonderful analogy he uses to illustrate the premise: Before germ theory, we held out hope for magical solutions, such as the fountain of youth, to solve all of our problems. Germ theory, however, told us that no magical solution was coming. Instead we have a long term, tedious war, that will have to struggle against for decades and decades, making slow slow progress. Yet, once we accepted that and stopped wasting all our time looking or waiting for magic, we were able to get to work on making the necessary incremental progress, and look where we are now.
Thus it's time to change our focus from the accidental complexity (of hardware limitations, etc) to the essential complexity of ameliorating the inherent difficulties of software development, which are its complexity (so much more intricate than other engineering disciplines), changeability (software is changed rapidly as compared with cars, for example), and invisibility (not naturally mapped onto a 2d visual plane).
Ok, I'll agree with him the programming is indeed harder than other kinds of engineering for greater complexity and change-ability. While fast changes are hard to deal with, version control in git and GitHub is pretty good, and I and others have a few ideas on how to improve this. Yet if it is indeed also inherently un-visualizable, than we are going to be hard pressed to address all the complexity in code.
But of course I strongly disagree that software is inherently un-visualizabe. I think if Brooks looked at the work of Bret Victor and Edward Tufte, he'd see that through innovative design work, we can increase the visualizablity of just about anything. While we might not have great visualizations today, have hope! Many visualizations that seem obvious now were not obvious before they were invented -- and it was in no small part data graphics that led the scientific journal revolution.
Additionally, I deem much of what Brooks refers to as essential difficulties in programming as accidental to how programming is done today, and not at all essential to solving the problems at hand.
Thought experiment: how long would it take for you to describe Twitter, the entire application, from the consumer's perspective, down to every interaction and pixel? Maybe a couple dozen hours, maybe a hundred, at the outset. Yet thousands of engineers are working on it every day. Why? 99% incidental complexity.
Of course, you may argue that to simply describe Twitter in English is not a fair test because English is not precise enough. So what language do we have that's 100% essential complexity, 0% incidental? My thought is that math is just such a language. It talks about conceptual objects and relations, not at all about how such things are computed (unless that's what you are talking about in math). And of course this is why I'm currently working on (as you can see in the last few entries below) describing UIs with only pure maths / piecewise functions with dynamic piece breaks.
100% agreed. So much of what stinks about programming today is that folder-and file interface of code. Impossible to navigate and communicate how things are built and run. I think a key way to overcome this is to build a sounder model for computation that lends itself better to communication and understanding (such as definitions only depend on explicit dependencies, and nowhere else).
Composibility is also key, particularly for re-using code and collaboration.
I haven't thought alot about OOP in a while. It's always felt lame to be, particularly because I learned it in Java and it was mostly about inheritance.
Yet there's one idea about it, encapsulation, which is kinda neat. The idea is restricting the mutation of state to a higher level operation, hiding the implementation details, and also limiting the number of pathways that can change state. Of course, in practice, objects often become dumb data structures and people just mutate their fields willy nilly with no encapsulation.
I think what OOP is missing here is being explicit about who can access those pathways under which conditions. In other words, being clear about what can effect certain pieces of state, what it depends upon, as opposed to the protocol by which it can be ordered about by.
I can't believe it's taken be so long to read this. It's just 1.5 pages. It's so great. Makes me think that even more of what we do to program is also harmful in a similar way. As I've been saying recently, everything but mathmatical expressions are harmful. A new thing that I've been against recently is dynamic scope and lexical scope. Names are super dumb. Content hashing is really the only way to go.
I had a lot of fun tweeting with Michael Nielsen on Twitter via his tools_4_thought account: https://twitter.com/stevekrouse/status/1002604633209131009
I also had success tweeting a Fred Brooks quote: https://twitter.com/stevekrouse/status/1002614810780094469
I find it hilarious how great Twitter is for this community!