I was watching Wall-E again recently. It’s a wonderful film and I’m astonished that something that well made was a mainstream success. I really like the bit when Wall-E is sorting through the day’s interesting items. He finds a spork and goes to put it into his little cutlery collection. At first he goes to put it with the spoons, then the forks, then the spoons again. Eventually he gives up and puts it in the middle by itself. I thought that was sweet and I recognised myself in that.
I’m of the opinion that that sort of thing makes a good developer. The urge or compulsion to sort and categorise things. Is it a spoon? Does it have spoon-like qualities? Could I perform standard spoon operations on it? Or for that matter, where do I file the latest Circus Devils album in my CD collection? C for Circus? P for Pollard, Robert (it’s one of his many bands)? G for Guided By Voices (it is / was his main project band)? Or just bung it in wherever it fits on the shelf like a normal person?
I’ve found that many developers have an obsession with lists, sorting, categorising, rules, patterns and conventions. And a good thing too. Code that is neatly sorted and grouped and code that follows established conventions is way easier to work with. In all programming languages that I can think of, it is perfectly legal to put all source code of a program into a single file. You may even be able to put it all in a single function in that single file. But your typical developer (typical good developer anyway) will split things up into neat little bundles. The neat little bundles will be put next to other neat little bundles that are most similar. They’ll be written in such a way that if you understand what one of them does, you could make a good guess at what the others do. Then whatever they have in common will be abstracted out – tidied away so that the bundles become that little bit neater. In Object Oriented Design and Programming this is a formal process. You can define things in terms of what they’re similar to.
And following convention is of great benefit. Pattern recognition seems to be another standard trait of a good developer. If one thing starts with an upper case letter, so will all similar things. If the FooAction class corresponds to the foo.jsp web page, then BarAction class will correspond to the bar.jsp web page. And you can bet that if I’ve started some pattern like this, my colleagues will pick up on it and do the same when they extend what I’ve done.
If you can assume that developers will follow conventions, then you can start to take short cuts. For example if you know that FooAction corresponds to foo.jsp, you don’t need to explicitly state that relationship in Struts or other MVC framework. Or if you assume that methods ending in test are Unit test methods then you don’t need to explicitly maintain a list of methods to be run in your test. And of course your standard Java Bean conventions mean that a class can define its own operations without having to write an explicit BeanInfo class.
Conventions increase readability of code. Conventions reduce number of hand coded lines of code to be written and maintained. Conventions make it easier for tools and frameworks to integrate with your code.
The downside of this is what happens when people don’t or can’t follow established conventions. Is there a way to ‘fix’ non compliant code? Can you state explicitly what would usually be understood by convention? Also, is it well understood what the convention is and what happens if you don’t follow it (see last week’s hissy fit on bean introspection rules).
I wonder if software development attracts people with this personality trait. Are naturally fastidious, anal-retentive people drawn to programming as a career? Or does the software engineering discipline nudge ordinary people toward this borderline OCD behavior?
Be First to Comment