Which is more important: the code you write, or the tools you use? Instinctively I would say it is the code which really counts; but vendors tend to focus on tools because that is what they sell. I found myself thinking about this last week, because while I was engaged in puzzling out the new Application Factories feature in CodeGear’s JBuilder 2008 a book arrived on my desk. It is called The ThoughtWorks Anthology, and subtitled “Essays on Software Technology and Innovation.” The title is the worst thing about it, since it sounds like some kind of corporate puffery from ThoughtWorks (and I suppose it is); but it is also a concise, enjoyable and stimulating read. I found it particularly refreshing as a break from JBuilder, since it it concerns stuff that matters: code, testing, project management, as opposed to stuff that might introduce more problems than it solves: the latest wonder tool which promises to speed development but might end up as just another piece of clutter.
I turned first to an entertaining chapter by Jeff Bay, called Object Calisthenics. Bay sets out nine rules; I don’t want to steal all his thunder, but here are three of them:
- Don’t use the else keyword
- Use only one dot per line
- Don’t use any classes with more than two instance variables
Before you scream at him, note that this is an exercise, not a set of rules for live projects, though at the end of the chapter Bay says they can be used as such. It doesn’t matter whether you agree or not; what counts is that it makes you think about how to improve the design of your code.
Martin Fowler writes about how to write a DSL (domain-specific language) in Ruby. Rebecca Parsons describes how to categorize languages. Neal Ford makes the case for polyglot programming. Erik Doernenburg discusses the use of annotations/attributes in Java and .NET for application domain metadata. Julian Simpson has a great chapter on refactoring Ant build files, which can easily become hard to maintain. Two final chapters cover test strategy and performance profiling strategy.
I particularly like the way in which the book itself reflects the coding principles it presents. Each chapter is short, clear and focused. A good read for your next transatlantic flight.
The ThoughtWorks Anthology (Pragmatic Publishing ISBN 10: 1-934356-14-X)
Amazon links:
Oh no, another book on dogmatic advice that is sure to lead to another generation programmers obsessing over inane ideas.
Some people need hard and fast rules to follow. They see the world as black and white, and they need solid direction from a perceived source of authority. Many developers are like that. Innovative, creative developers who can make their own competent judgement calls about design are frankly a rarity. And I’d rather have a developer following a set of rules, even if they are somewhat restrictive, than a developer writing continuous streams of unmaintainable uncommented garbage code. In any case, any methodology can only be a guideline, an approach that we attempt to adhere to as best we can while meeting the needs of our clients. Only in research or example projects can architectures be developed that perfectly fit any non-trivial methodology. The real world is always more complex and exception-ridden than the products of such methodologies: ideal structures that appeal to us aesthetically, or readily lend themselves to maintainability.