Your current filters are…
by Neal Ford
Reading and hearing about agile practices is one thing, but actually doing it is completely different. This workshop puts you to work in an agile fashion, applying agile development practices. During this workshop, we’re going to take a problem and iteratively develop the solution, using test-driven development, pair programming, retrospectives, pair rotation, and other agile development techniques. To make it interesting, we’re going to split the room into two continents and work through the issues faced by real distributed agile teams. We work through several 20-minute iterations during the workshop, giving you a hands-on feel for real agile development. If you have a laptop, bring it, but only half the class needs one, so if you don’t have a laptop, don’t let it discourage you. Come see what it’s like to work on a real distributed agile project, even if it’s only for a few hours.
TDD seems to take all the credit for getting software designed right these days. But how do you approach a User Story or a whole application with TDD? Use UML? Right – except hardly anybody does. So let’s get real: whoever said object orientation would make designing software easy, was wrong. OOAD, UML, even Clean Code are not easy, not even intuitive. Enter flow-orientation. If you temporarily give up any fixation on “real” objects there is a way to escape many design difficulties. Want a design that is easily readable? Want a design method that lends itself to teamwork? Want a design method that can describe software on any number of abstraction levels – and can easily and losslessly be translated into code? Want designs that result in code that can be tested without mock-ups? Flow-oriented designs promise to give you this and more. It’s designing software the smart way; it brings out the best in groups. And there is still a place for “real” objects. Promised.
by Neal Ford
This session describes the current thinking about emergent design, discovering design in code. The hazard of Big Design Up Front in software is that you don’t yet know what you don’t know, and design decisions made too early are just speculations without facts. Emergent design techniques allow you to wait until the last responsible moment to make design decisions. This talk covers four areas: emergent design enablers, battling things that make emergent design hard, finding idiomatic patterns, and how to leverage the patterns you find. It includes both proactive (test-driven development) and reactive (refactoring, metrics, visualisations, tests) approaches to discovering design, and discusses the use of custom attributes, DSLs, and other techniques for utilising them. The goal of this talk is to provide nomenclature, strategies, and techniques for allowing design to emerge from projects as they proceed, keeping your code in sync with the problem domain.