Kevlin Henney
Biography
Kevlin Henney (@KevlinHenney) is an independent consultant and trainer based in the UK. His development interests are in patterns, programming, practice and process. He has been a columnist for various magazines and web sites, including Better Software, The Register, Application Development Advisor, Java Report and the C/C++ Users Journal. Kevlin is co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He is also editor of the 97 Things Every Programmer Should Know site and book.
Lectures
Seven Ineffective Coding Habits of Many Java Programmers
Habits help you manage the complexity of code. You apply existing skill and knowledge automatically to the detail while focusing on the bigger picture. But because you acquire habits largely by imitation, and rarely question them, how do you know your habits are effective? Many of the habits and conventions Java programmers have for naming, formatting, commenting and unit testing do not stand up as rational and practical on closer inspection. This session examines seven coding habits that are not as effective as many Java programmers believe, and suggests alternatives.
Worse Is Better, for Better or for Worse
Over two 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 complete. 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 question, and look at how this approach to development can still teach us something surprising and new.
back to speakers
