On the delivery side of things, I liked the way he used short stories, metaphors and challenging questions to make his points. The beauty of his approach was, I could either it at face value, or re-examine my assumptions and paradigms. I think I ended up experiencing recursive insight.
On the content side, I Iiked Brian’s points:
- Leave your goalie there. No matter how good your game strategy is, would you risk playing without your goalie?
- Do it when it counts. If you’re going to check it later do you need to check it now? Are you checking it at the most effective time? Are you checking when it matters most? Are you checking too much or too often?
- End-to-end testing. what happens when there’s a mistake in your model? did you simulate enough in your end-to-end to spot the problem?
- Readable code. If you can’t eyeball your code, who’s going to catch what the compiler won’t?
A highlight for me was when Brian asked the question, what would or should have caught the error? (the example he showed was a significant blunder measured in millions) There’s a lot of factors across the people, process and technology spectrum. The problem is, are specs executable? … are processes executable? are engineers executable? … etc.
After the talk, I had to ask Brian what lead him to Big Ball of Mud. I wasn’t familiar with it, but more importantly I wanted Brian’s take. My guess was it was a combination of a big ball of spaghetti that was as clear as mud. He said ball of mud was actually a fairly common expression at the time, and it hit home.
Following one ponderable thought after another, we landed on the topic of copy and paste reuse in terms of code. We all know the downsides of copy and paste, but Brian mentioned the upside that cut and paste localizes changes (you could make a change here, without breaking code there). Dragos and I also brought up the issue of over-engineering reuse and how sometimes reverse engineering is more expensive than a fresh start. In other words, sometimes so much energy and effort has been put into a great big resusable gob of goo, but you just need to do one thing, that the one thing is tough to do. I did point out that the copy and paste-ability factor seemed to go up if you found the recurring domain problems inside of recurring application features inside of recurring application types.
Things got really interesting when we explored how languages could go from generalized to optimized as you walk the stack from lower-level framework type code up to more domain specific applications. We didn’t talk specifically about domain specific languages, but we did play out the concept which turned into metaphors of one-size fits all mammals versus trucks with hoses that put out fires and trucks that dump dirt (i.e. use the right, optimized tool for the job).