In the days before Agile, programmers were often arrogant. They acted as if a business domain was complicated or messy only because the people in that business were not clear thinkers. So our programmers wrote code for a “rationalized” domain — for the way the world *should be*, rather than for how it is. Then — if they were lucky — the programmers would move on before everyone discovered the good reasons for most of what they’d ignored.
Agile programmers are supposed to be more humble. They are supposed to want to learn the domain — not with the goal of “fixing it”, but so they can effectively collaborate with their customers: understanding what they want, being able to explain alternative implementations in understandable ways, and so on.
Learning a domain is a skill, just like anything else. But it’s not something people are normally taught. Instead, programmers are just dumped into a project and told to learn the domain, somehow.
But actually people have been learning complex and subtle domains for thousands of years. This talk will talk about two ways that they’ve done it — ways that you can apply to your next project.