Are you "doing it" the TDD way? Really? Are you getting the results from TDD as you expected? Yes? Great, check out one of the other exciting sessions at this conference.

No? Then: How come? Isn't TDD supposed to be easy? Just do the red-green-refactor dance and all code's gonna be functional plus clean.

Sorry, but I beg to differ. It's not that simple. And there are many reasons for that as I'll show you in this talk.

My main objection is, that TDD as it's commonly explained and demoed, is ignoring the plain and simple reality of problems being of very, very different difficulty. Or have you ever seen a TDD demo beyond the usual code kata exercises like "Fizz Buzz" or "Game of Life"?

Hence in this talk I want to present a bigger picture. I'll classify programming situations according to the Cynefin framework and put TDD in perspective. It will become clear where TDD might be a good fit and why - but also, where TDD is overtaxed.

And since TDD is only a fit for a small subset of problems, of course alternative approaches to test-first programming will be presented.

Starting software development from use cases and user stories sounds great. You get a more structured view of requirements and you get a less pseudo-accurate deliverable to transform into code.

Unfortunately neither requirements description was invented with developers in mind. Because neither comes with a mapping to code and its structures. Sure, it's just requirements, not designs. But still... How to move on towards code from a use case or a user story? The developer is pretty much left alone with that. Also requirements easily get dissolved in code like sugar in a cup of tea: the code's capabilities are increased, but there is hardly a link to the specific requirements. That leads to waste of all sorts and negative effects: meetings, overengineering, bugs, conflicts, false promises, overconfidence...

What makes developers happy, on the other hand, are scenarios like they get presented in coding dojos: clear, focused, close to code.

In my talk I'll present a lightweight, framework rooted in Agile thinking for processing requirements from broad/comprehensive to narrow/detailed in a way so that the subsequent creation of designs and code is well supported. You'll learn simple criteria for "good" requirements - and what to do when they are not "good" (yet). And you'll get acquainted with a "language" you can use with users/POs to drill down into requirements while getting hints for design and implementation. This is satisfying for both sides: developers feel valued with their background leading the process and produce tangible starting points for further development, users/POs feel understood and guided through a process of incremental refinement of their ideas.

Requirements engineering is a vast subject. But in the end it all boils down to: Does a developer understand where to start implementation or where to change code? And maybe even, how is incremental software development possible?

Use cases and user stories might be a good starting point, but their shortcomings in programmer guidance should be compensated. Users/POs and developers need to meet on eye-level.

Why is the fight against technical debt such an uphill battle? Why is it so hard to nip technical debt in the bud or at least keep it much better under control? If after so many years of the metaphor circulating around in developer circles little has changed, there seems to be an underlying unresolved issue.

This talk is dedicated to uncovering an inconvenient truth: There is no such thing as technical debt in the first place. Hence fighting it is like fighting against non-existing windmills.

But what about the deficient code situation the term is referring to. Isn't that all too real and painful? Yes, it sure is. But it should not be called a debt, because it does not accumulate like a financial debt which the term technical debt is alluding to. Rather it's a mess, a mess like that created by any addict.

Managers and developers thus don't need to learn to manage just another form of debt. Instead, they need to sober up. They need to get clean. They need to recognise what's happening in everyday software development under deadline pressure as what it is: the behavior of addicts.

In my talk, I will contrast the signature aspects of debt and addiction. It will become clear and will be supported by the audience's own experience why debt is the wrong metaphor and addiction is a much more fitting notion. And then I'll talk about interventions. How to climb out of the bottomless hole of addiction and get on the track of longterm high productivity.