Here’s the third in my series of notes taken from keynotes at CUSEC 2010, the 2010 edition of the Canadian University Software Engineering Conference. These are from Beautiful Failure, a keynote given by my friend Reg “Raganwald” Braithwaite, who’s forgotten more about combinators than I will ever learn.
My notes from his keynote appear below; Reg has also published his slides online.
- I gave a talk at Stack Overflow DevDays Toronto in which I was thinking out loud about programming about programming
- I was trying to rewrite the way we program
- The language we use for coding guides the way we think about the program and the solutions
- When you write things to change your programming language, you change the way you think
Thinking About Programming About Programming
- I often get called in by clients to automate a process
- Often, during this process, they want to change the process that I’m supposed to automate
- Automating a process forces you to think about it
- The very act of thinking about how you do things helps you understand what it is you do
- The exercise of thinking it through is useful, even if it fails or you don’t end up using it
- Languages and frameworks come and go, but everything you to do fix what’s between your ears stays with you forever
- Programming languages are just a notation for the way we think
- Some people try to do things like add a "sum" method to Ruby’s
Enumerablemixin - What happen when you try [[1, 2], [3, 4], [5, 6]].sum?
- [He showed two implementations of a “sum” method:
- One by “Alice”, which when applied to [[1, 2], [3, 4], [5, 6]], yielded 21,
- and one by “Bob”, which when applied to [[1, 2], [3, 4], [5, 6]], yielded [1, 2, 3, 4, 5, 6]
- With “monkeypatching”, it’s possible for two different modules to implement
Enumerable#sum, and then for someone else to import both modules.- In which case, which version of sum will get called? It depends on the load order of the module
- But what if these were written as gems? Then there’s trouble
- To solve this sort of problem, I decided to steal extension methods from C# and add them to Ruby [Joey’s note: extension methods are a C# feature that let you add methods to an existing class without subclassing]
- It works, but what’s wrong with what I’ve done?
- My extension methods for Ruby are a hack…
- to fix Alice and Bob’s hack…
- of Matz’s (Yukihiro Matsumoto) hack of Smalltalk’s hack (i.e., Ruby)
- It eliminates the annoyance without solving the core problem
- Do extension methods reengineer the way we think about problems? Or do they simply deal with an annoyance?
- Do they reengineer the way we think about programs?
- Take the Single Responsibility Principle (SRP)
- When you write an extension method, you break SRP
- When you monkeypatch, you violate SRP
- Is that bad? I don’t know
- C# breaks SRP with extension methods
- Rails "runs roughshod over it"
- If two popular languages break SRP, maybe SRP isn’t all that
- What does the sum method tell us?
- Why is this a beautiful failure?
- Maybe we’ve gone beyond the class — Ruby is not C++ or Smalltalk
- Hacks like this scratch an itch and suggest a flaw — what else is flawed?
- You have an advantage over me
- I have this ball and chain of experience
- I’ve been fucking with computers for almost 40 years
- They way I’ve been doing things has made me a living; I’m not incented to change the way I do things
- You’re not tied down
- So now I present a few ideas that have occurred to me — think about them!
- I don’t have the answers
- Unit tests tell us that compilers are flawed
- If we need them, what is wrong with our programming languages and compilers that requires us to step out of what we’re doing to implement them?
- Why do we need to take a great language and bolt something onto the side?
- Github tells us that our existing idea of a program is flawed
- Most people think of programs as static things
- In Github, there is no "program" — there are branches, forks and tags
- Languages themselves have no notion of what a version is
- Looking at the way we actually use tools shows that there’s a disconnect between our toolsets and the way we write code
- Are Github commits congruent to objects?
- If you change 4 classes in a commit, there must be something they have in common, but that’s not apparent from the way we write them
- Do we manage work the way we manage code?
- Project management seems awfully disconnected from our tool chain
- Consider the complete disconnect between issue tracking and time tracking
- Maybe not so important in your company, but more important for personal projects
- Git and Lighthouse — “like two cups connected by string”
- Do we manage object versions the way we manage API versions?
- "Do not follow in the footsteps of the sages, seek what they sought."
- What I think is particularly cool and interesting is…but to me
- Think about what your heroes were trying to achieve using the tools available to you today
- An example of following blindly in the footsteps of sages:
- In November 2002, I attended Paul Graham’s “Lightweight Languages 2” conference in Boston
- The morning keynote was by John Armstrong, who presented Erlang, which today is considered an important language for concurrent programming
- The afternoon keynotes was Matz, who presented Ruby, one of the most influential dynamic languages that soon after enjoyed a meteoric rise in popularity
- Many people in the room, die-hard Lisp-heads, were shouting them down because their languages didn’t have macros [Joey’s note: Macros are a Lisp feature that smug Lisp weenies often use in the never-ending “Why my language is better than your language” argument]
Four Ugly Failure Modes and How to Avoid Them
Confusing correlation with causation
- I think it’s one of the most prevalent diseases in the business world
- Ruby is not a silver bullet
- Was the success of many Ruby projects [such as Rails and Twitter] because of Ruby the language?
- Or was it that smart people who could get things done were picking Ruby at a given point in time?
- Agile is not a process
- It’s a set of values
- Here’s how many companies fail:
- They start a little consulting company
- They enjoy some successes, which leads to more business
- As a result, they hire people and the company grows
- But they can’t hire smart people faster than the work is coming in
- So in order to hire people to meet the demand, they start hiring people who aren’t as smart
- That’s when things go downhill
- Who here doesn’t think this isn’t standard for any consulting company?
- Toronto Agile User Group recruiting process
- In our field, "best practices" are cow patties
- I’ve gone to many companies where they combine "best practices" simply by smooshing them together
- I’ve been to many Toronto Agile User Group meetings where very few attendees work at companies that even practice agile
- The important thing is that the people there are attending because interested in finding a better way of doing their work – those are the people you should be hiring!
- The plural of "anecdote" is not "data"
- Greg Wilson will talk about this in his keynote later today – listen to him!
- Problem: Talks are given by narcissists (or masochists)
- When you read something in a blog, see something on TV or buy a book, you’re not getting a large enough sample, and the content is biased
- Another problem is that history is written by the survivors
- People write about really notable successes or failures
Confirmation bias
- "Most of you will be immune to this, because you’re all sensible people"
- You might fall victim to confirmation bias if you have an overly-inflated (or under-inflated) ego
- You might also fall victim to it if your worldview is too narrow
- If you’re a Ruby developer, you probably don’t read C# blogs, and vice versa
- Seek out more representative info; not just the stuff that confirms your opinions
Local maxima
- The innovator’s dilemma
- If you have customers, they will trap you in a local maximum
- They’re not trying to be mean, they’re trying to give you money
- You might end up optimizing to serve your customer base while the rest of the world (and eventually your business moves on)
- The Principle of Least Surprise is a trap!
- Familiarity comes from doing the old things the old way
- This doesn’t apply to just UI, but also naming variables or coding styles
- Once in a while, you should say "Maybe this one time, we should do things differently"
- Iterative anything is a trap
- It’s hill climbing
- Sometimes you have to leap
- It’s supposed to be bad to "go dark" in development for a longer period rather than go through many small iterations, but sometimes it’s the only way to make a great leap
- You can’t climb a big mountain if you do things in small increments
"A Market for Lemons"
- What happens when you sell to people who don’t fundamentally understand what they’re buying?
- If customers don’t understand what they’re buying, they make their decisions based on easily differentiable features
- One example is buying a house, which you’re not going to do very often in your life, so most people know very little about it
- As a result, they focus on easily differentiable features like square footage, number of rooms, and other features that can easily be picked out
- But it’s better to focus on whether the house’s design makes it more liveable, which is harder to suss out
- Another example of this is feature checklists on the back of product boxes
- Gresham’s Law — “bad money drives out good” — applies to talent: When you have good currency and bad currency in an economy, the bad currency drives the good currency out
- This happens in Cuba, where the good currency – black market US dollars – gets hoarded while the local currency gets spent
- It also applies to information: people put the crappy information out, and it drives the good information down
- It also applies to talent: headhunters, not knowing what sort of people to look for, end up grabbing the people who put the most buzzwords on their resumes
- You don’t want to be one of those buyers
At the end of the presentation, posted a slide dedicated to his late friend, Sam Roweis (1972 – 2010).
