JavaZone 2009 - Reconsidering cherished design dogmas
Reuse, genericity and decoupling have recently been treated as the very goals of software development. But they are not.
You probably feel you should reuse as much code as possible, be it your own, that of you organization or third party open source or commercial software. But just because the code is already written doesn't mean you won't have to understand, debug and maybe even change it.
You probably feel you should write your code in a generic fashion so it can be reused. But generic code can be harder to understand. And making a piece of code flexible to certain kinds of changes will make it less flexible to other changes. Moving decisions to configuration can make your code more generic, but often, it will increase the cost of change.
You have probably learned that you must reduce the extent to which parts of your code is coupled to each other if you are to create maintainable code. So all your objects reference each other through interfaces and are wired together in huge XML files. But this makes the code harder to navigate and refactor.
In the quest for better software reuse, genericity and decoupling has become ends in themselves. In this talk, we will show how examples of how contemporary notions of good design have led us and others to solutions that are overly complex.
"A good design" is not a goal in itself. The goal is a system that requires as little effort as possible to develop and change. Proper use of reuse, decoupling and genericity can help with this goal. Improper use almost always hurts.
So how do you measure something like simplicity? We would like to revive an often reviled metric: Lines of code. More specifically, how many executable statements do you have to deal with to maintain the code?
Software developers have to be smart. But if you sometimes get the feeling we're too smart for our own good, this talk is for you.
Finn-Robert Kristensen
Finn-Robert has been working as a java developer for eight years and his working title is architect. His passion for developing software started when he got his first commodore 64 and he has been striving for good design since. He has fallen into many pitfalls, but feels he has learned from his mistakes.
Johannes Brodwall
Johannes is just a developer (but his business card reads "chief scientist" and his project plan gives him the august title "architect"). He's crafted code for ten years. When he started out, he wrote simplistic code. Then he learned to write elegant code. Now, he just tries to write simple code.