Although the “test” in its name, Test-Driven Development can be seen as a design technique. However, TDD does not create beautiful designs by itself; instead, it warns developers about a design issue. It is up to developers to interpret this feedback and use it to improve the design. In this talk, I will cover some feedbacks a simple unit test can give, and how to use good object-oriented practices and principles (such as SOLID) in order to achieve a good design. The main line of this talk is: “If it is hard to test, then it has a design problem”.

Managing software debt to an appropriate level can be difficult for Agile teams racing to deliver features to customers. It is even more difficult since many forms of software debt are hard to identify without the aid of external tools. Chris Sterling, author of the book Managing Software Debt, will show real world examples of how to put tools, monitoring, and organizational structures in place to manage software debt by raising early indicators across all types of software debt: technical, quality, configuration management, design, and platform experience.

TDD can produce an improved design, very low defects, and tests that double as documentation. Done poorly, it can result in a tangled mess—to the point where developers consider it a waste of time and throw out all the tests. Topics covered include:

• Potential TDD benefits
• FIRST properties of unit tests
• Test-first vs. test-after
• How TDD shapes design
• Tests as documentation
• Better tests using BDD
• London school or classic school?
• Appropriate metrics and standards
• How to avoid the Bad Test Death Spiral
• Test smells/remedies
• Sustaining TDD

An overview of model-driven development and the new concept of “continuous model transformation” within the context of agile projects accompanied by real-world examples based on an open source MDD toolkit. A discussion of how using MDD and Agile together results in higher quality results though continual shortening of the development-feedback loop and template-based evolutionary architecture methods. How to use MDD to generate automated tests to jump-start test development. This talk will present a case study of two successful projects that demonstrate the MDD-Agile value proposition.

Patterns have been known as “Solutions to Recurring Problems in a Context.” However, they are really more than just that. Alexander, the inspirer of design patterns in general and the author of this quote later says at the end of his book–“At this final stage, the patterns are no longer important: the patterns have taught you to be receptive to what is real.” This talk is about the thought process of patterns–what to be receptive to. These concepts will be discussed in the context of emerging application architectures and so will be of particular interest to agile developers.

User Experience designers like to get things perfect. We like screens to look great, we like to spend time finessing designs and we like them to work perfectly for everyone including the one person in a million who wants to send a dog in a box in an aeroplane. This takes time. Sometimes a lot of time. And this approach doesn’t always work in an agile environment.

So when is enough enough? How can you be sure that you’re not compromising the user experience by not designing things to be absolutely pixel perfect every time?

BA introduced User Centred Design into its waterfall software development in 2006. A couple of years later, the world changed and the IT department launched into Agile at warp speed with the UX team left following in a shuttle craft figuring out how to adapt.

In an Agile fashion, we conducted a ‘Retro’ with the User Experience team and other project stakeholders (mainly scrum masters & customer proxies) to establish what has worked well with the change, what hasn’t, what lessons we’ve learnt and any puzzles we still need to work on.

The company’s transition from waterfall to agile development disrupted how a centralized User Experience Team worked with the product development organization. This experience report of developing a new product in the early phase of the transition exposed challenges for designers and researchers as they learned to effectively work with each other, developers, product owners and stakeholders. The outcome provided insight on how cross functional teams collaborated to release a high quality product after adopting agile.

The different nature of functional languages can lead to a different perspective on test-driven design: 1) that the soul of the program is a network of relationships among facts-about-functions, 2) that tests are a usefully more abstract way of describing that network than is the program itself, and 3) that data structures should not be designed because they are better viewed as an epiphenomenon—froth thrown off by the network as it computes.

In this session, we’ll show these claims in action and question them. The example will be in Clojure, but knowledge of Clojure is not required.

Functional programming (FP) is going mainstream. First seen as a better approach for concurrency, we are finding that FP has pervasive benefits, often supplanting OOP for many purposes. This talk explores how FP aligns with, but also changes developer principles and practices.

1. FP emphasizes mathematical rigor and rich types, which change TDD.
2. Capturing your domain model in code has serious drawbacks.
3. Pure functions and immutable data structures are more modular and reusable than objects.
4. FP introduces new “design patterns”.
5. But, FP can be hard to master.