Agile Singapore 2014 Conference

I have been practicing test driven development (TDD) over four years. I believe Baby Step is one of most difficult parts by learning TDD. "How should I choose the next test to drive my code in the easiest and smallest way?" is a very common question raised by TDD newbies. Unlike refactoring, there is no clear describable methodology in this area. Near the end of year 2010, Uncle Bob created a concept called Transformation Priority Premise (TPP) which throw a light into this area.
In this talk, I will share my thoughts and experiences of applying TPP in TDD. Here are key points of this talk.
How can TPP help to do baby step in TDD TPP Deep Dive
A wrong order in current TPP list? I will explain it with my experience report by applying TPP in one of my recent Kata https://github.com/JosephYao/KataNumbersInWord
TPP and Problem splitting in TDD. I will talk about how I see TPP working together with the problem splitting skill we apply in TDD, which is a key value of TDD as design methodology.
How is TPP related to refactoring? I will explain how to identify the real transformation given that doing transformation and refactoring in one TDD cycle.
Based on my experience, there could be main transformation and sub transformation when applying TPP
As a learning outcome of this talk, I hope audiences can see TPP as a way to learn baby step in TDD and get some ideas about how to apply TPP more clearly and intensively when doing TDD.

Technical excellence is more than two week sprints, a burn-down chart and a daily stand-up meeting. The basic rules of Agile or Scrum are not an end in themselves, but rather a staring point based upon principles and practices that allow and encourage teams to adopt, adapt, and refine their craft. Unfortunately, it may seem to the technical people that agile is just another micro-management approach.
Extreme Programming with its provocative name, got people’s attention in 1999. It is based on sound technical practices. Why do so few agile teams employ engineering practices that support the tight iterative cycles of Agile and Scrum? The founders of Scrum expected the continuous improvement cycle to pull engineering practices into teams once the cycle revealed the problems of poor product quality, hard to change code, wasted time debugging, long stabilization efforts and the ever growing burden of manual test.
In this talk we’ll look at why the technical practices of test-driven development, refactoring, continuous design, clean code and automated testing can help you and your organization be great.

Nearly two-and-a-half decades ago, Richard Gabriel proposed the idea of “Worse Is Better” to explain why some things that are designed to be pure and perfect are eclipsed by solutions that are seemingly compromised and imperfect. This is not simply the observation that things should be better but are not, or that flawed and ill-considered solutions are superior to those created with intention, but that many solutions that are narrow and incomplete work out better than the solutions conceived of as being comprehensive and all encompassing. Whether it is programming languages, operating systems, development processes or development practices, we find many examples of this in software development, some more provocative and surprising than others.
In this talk we revisit the original premise and definition, and look at how this approach to development can still teach us something surprising and new.

Test-Driven Development (TDD) has been so successful that it's now unfashionable. But many developers complain that being required to write tests just gets in the way of shipping features. That wasn't our experience when we first stumbled onto TDD a dozen years ago, so what went wrong? Were we fooling ourselves, or did the message get confused along the way?

In this talk, I will revisit the basics, the essence of what makes TDD work. I will look at some of the common difficulties that I see with teams that are struggling. I will show how understanding the principles means that we can use tests to help us deliver more effectively.

These days testing is considered sexy for programmers. Who'd have thought it? But there is a lot more to effective programmer testing than the fashionable donning of a unit-testing framework: writing Good Unit Tests (GUTs) involves (a lot) more than knowledge of assertion syntax.

Testing represents a form of communication and, as such, it offers multiple levels and forms of feedback, not just basic defect detection. Effective unit testing requires an understanding of what forms of feedback and communication are offered by tests, and what styles encourage or discourage such qualities.

What style of test partitioning is most common, and yet scales poorly and is ineffective at properly expressing the behaviour of a class or component? What styles, tricks and tips can be used to make tests more specification-like and scalable to large codebaes?

When we plan and manage projects, we are seldom given a blank page. We have staffing and scheduling concerns, and a variety of other issues to contend with, but below each of them is the one thing that affects completion and effort more than anything else: the quality of the existing code.
In this talk, Michael Feathers will outline managerial and team strategies for moving projects forward in the context of code that is hard to change. We'll talk about how to manage risk, how to create new opportunities moving forward, and how to work in ways which avoid to creation of further problems in large existing code bases.

Why can’t we just add a feature to our system without tearing the code apart or, worse, patching around it? It ought to take just a few lines. We know the code is supposed to be modular and coherent, but too often it just doesn’t turn out that way.

We don’t believe it should be this hard to change object-oriented systems. We’ve seen examples where it really is that easy to add a new feature. The difference seems to be in the intermediate level structure. The design principles that most programmers rely on don’t address the middle ground where the complexity lies. We know about principles and patterns at the small scale, such as SOLID, and the large scale, such as REST. We’re less familiar with the structures in the middle.

This talk is about design principles that we’ve learned help us develop mid-scale code structures that are easy to read and easy to change. At the lowest level, this means well-known patterns such as avoiding globals and following SOLID guidelines. At larger scales, this means assembling those SOLID objects to avoid hidden coupling so that the system as a whole is amenable to change. We focus on how objects fit together and communicate, and on being clear about how capabilities and information flow between objects in the running system.

The main message is continuous delivery of real value while dealing with complex technical challenges. In other words, don't say 'no’ to business because systems are old or a "big ball of mud". A problem many large enterprise organisations have today begins with a promise of business value over few year. But first thing an IT department “needs" to do is implementation of some technical fundament or legacy replacement, while business is waiting.

This is a story about gradual replacement (StranglerApplication) of large, business-critical, 24/7 systems with very high quality requirements, used Agile practices in dealing with architecture, migration, and enterprise aspects. It is about new way in dealing with complex architectural questions (compared to traditional architecture processes) where everyone is involved, emergent design, and simplicity.

It is also a real-life story about 4 cross-functional Scrum / DevOps / feature teams working together and with many stakeholders for 4 years, delivering value with new version in production, every 2 weeks. The talk is an example of false dichotomies that agile and architecture need to compromise, or "without QA people you will have a big mess in such projects".
The story can also be read in this paper. It is currently being edited for posting on InfoQ.