Abstract: Model-driven systems are gaining in importance but haven't received broad platform support yet. Models were initially used for purposes of human communication and artifact verification/specification. In the next stage, models are used in model-assisted systems: systems were artifacts are partially generated from models. Microsoft's Codename "Oslo" is the first wave of a new Modeling Platform that specifically aims at model-driven systems. Such systems retain models throughout their lifecycle and are driven directly by models rather than indirectly through generative technologies. "Oslo" delivers three pieces: a modeling language, a modeling tool, and a model repository. In this talk, I will go into the details of and rationale behind these technologies.

Abstract: Cognitive scientists tell us that we are hardwired for deception. It seems we are overly optimistic, and, in fact, we wouldn't have survived without this trait. With this built-in bias as a starting point, it's almost impossible for us to estimate accurately. That doesn't mean all is lost. We must simply accept that our estimates are best guesses and continually re-evaluate as we go, which is, of course, the agile approach to managing change. Linda Rising has been part of many plan-driven development projects where sincere, honest people with integrity wanted to make the best estimates possible and used many "scientific" approaches to make it happen - all for naught. Re-estimation was regarded as an admission of failure to do the best up-front estimate and resulted in a lot of overhead and meetings to try to "get it right." Offering examples from ordinary life - especially from the way people eat and drink - Linda demonstrates how hard it is for us to see our poor estimating skills and helps us learn to avoid the self-deception that is hardwired in all of us.

Abstract: The bad news: applications are more complex and error-prone than ever. Site development projects are really enterprise application integration projects in disguise. SOA portends far-flung interdependencies among unreliable services. Failures will spread wider and wider, reaching across your company and even crossing boundaries between companies. How do monumentally costly failures begin, develop, and spread? Can they be averted? Once you hit Release 1.0, your system will be living in the real world. It has to survive everything the messy, noisy real world can throw at it: from flash mobs to Slashdot. Once the public starts beating on your system, it has to survive without you. Did you know that just having your database behind a firewall can bring down your system? I'll show you that and many other risks to your system. You will learn the biggest risks to your system and how to counter them with stability design patterns. We'll talk about the best way to define the term "availability" and why the textbooks get it all wrong. In this session, you will learn why the path to success begins with a failure-oriented mindset. I'll talk about numerous antipatterns that have caused and accelerated millions of dollars worth of system failures. I'll share some of my scars and war stories with you (don't worry, they're all suitable for polite company) in the hopes that you can avoid some of these costly disasters.

Abstract: In part 1, we looked at common sources of system failure: those commonly created structures that exacerbate problems. Now, we'll take on Stability Patterns that not only stop the antipatterns, but also add resilience to your system. Apply your new failure-oriented mindset to unchain yourself from the pager and save your company from embarrassing, and costly, disasters. These patterns combat entire classes of failure modes, making your system robust against even unforeseen problems. Books on design and architecture only tell you how to meet functional requirements. They help your software pass Quality Assurance. But painful experience has shown that "feature complete" is not even close to "production ready." After this talk, you'll be prepared to use your failure-oriented mindset to make your system a success.

Abstract: As agile moves strongly into the software development mainstream it would be easy to believe that the choice facing developers is simply whether to be agile or not (is that ponderous?). However there is no single way to "do agile" - deciding what practices should become part of your agile play book can be a difficult and time consuming journey, and there is no single destination. Given a plethora of agile practices, how does a team (or an individual) even know where to begin? Despite their breadth, the many agile practices are characterised by consistency with some underlying values, so a team would do well to understand these values and whether they are ready to act congruently with these values. We'll begin by looking at three different versions of the agile values - the original Agile Manifesto, Brian Marick's recent revisiting in his Agile 2008 keynote presentation, and Kent Beck's values of accountability, responsibility and transparency. Once we understand the foundation values of agile development we can begin to look at how different contexts may constrain your choices of agile practices and tools, and how these choices in turn constrain your outcomes.