Are you overengineering your application code? What if I told you about a way to remove 30% of the code? What if I told you that the removal of code will increase code quality and make maintenance easier?

Application code is what most of us write, but the code we interact with is mostly library code. We use it from our applications and we get inspired by the coding style. But while code might look like code, the requirements are very different. Library code needs to reusable across different applications and different development teams.

When writing library code, many of the classical design pattern can help: factories, strategies, dependency injection, and inversion of control. Public classes and methods form contracts of the API to its consumers. Protected methods and properties are also contracts. They are used by anyone extending functionality through inheritance. Knowing about these patterns makes it easier to find your way through library code and find the right hooking points when you need to extend/adapt the functionality of a library.

But while these patterns are powerful and necessary for a library, they are often just overdesign and extra work for an application.

Anders has extensive experience in developing and maintaining both large applications and libraries with millions of downloads. In this talk he shares some real world examples and opinions on what it takes to make a library reusable. He also explains why you shouldn't do that extra work in your applications and shows you what to do instead.