Once a project has chosen an appropriate architecture, it's all about the code. We have all joined projects which have good response time and supports the required number of users, but is impossible to maintain. Why?

We have all developed for one year in the same project and saw it becoming dirtier and dirties, until it reached the point of no return, the dark whole of code quality.

It can't be something nasty and big. We don't do big nasty things. So where are all those small nasty things that we do, that accumulate over time, culminating in that horrible piece of software that no one wants to maintain?

While developing, design and code decisions influenced its quality in a way that its impossible to say what happens, when it happens and where it happens. It is time to take code in our hands and care about it: not only on the short term, but also on the long run. This talk will go through some of the small and controversial decisions, that affect code both on the short and the long run. Issues with AOP for business logic, concise code, bad tests, long code and so on; always mentioning how average and above average developers affect those projects.

Another important point is that smaller projects are easier to be rewritten: should we favor them to always keep code in shape?

Note that as this is not a language specific issue, we will go through examples of perfect running code, that is impossible to maintain, in Java, Scala and Ruby.

If you are tired of seeing the same code design mistakes, while just jumping from one language to another, this session is for you. Come and also share your examples on poor code design.

The keywords for the workshop are: TDD, Design, Quality, java, ruby, .net, scala, OO, Solid, Patterns

The target audience: Developers and architects who care about good quality. Those who want to improve their design based on TDD and those who want to improve their TDD practices based on design.