Thursday, July 12, 2007

Tinkerers, Platonists, and Communicators

I've written on this topic before but lately I've been thinking some more about the differences of perspective people have about software development and I came up with the idea that there are three pure personality types in software development: Tinkerers, Platonists, and Communicators. That's my attempt to neologize a la Martin Fowler by the way! Each type tends to focus on one aspect of development over others, and I think we all tend to fall into the trap emphasizing our own inclinations and downplaying the importance of the other perspectives. I suspect most of us have some attributes of each type but that developers can probably be identified as mostly leaning toward one of these types more than the others. Here then are my descriptions of each type!

The Tinkerer: The tinkerer is someone who generally thinks of programming as an adjunct to other things. Some examples: A stock broker might write some macros in excel to crunch some financial numbers. An engineer might need to write some drivers for a piece of hardware s/he designed. A network administrator might cook up some scripts in perl to help manage repetitive tasks or analyse network traffic. The tinkerer's sweet spot is in getting things configured, finding ad-hoc optimizations, and writing quick and dirty hacks that get the job done. The big weakness of the tinkerer is scaling software to the point where it has to be maintained on an ongoing basis, especially if multiple developers become involved. Tinkerers may not to recognize such risks and are generally comfortable with a certain amount of messiness. Tinkerers are great people to have on a team when you need to figure out how to make something work - they love finding out about all of the different options a piece of software or hardware has and can find a way to make something work even if the tools that are being used don't make it easy. I think Linus Torvalds is an archetypal tinkerer.

The Platonist: The platonist is in many ways the diametric opposite of the tinkerer. They're not interested in nitty gritty details. They enjoy working with pure and abstract ideas and they want to solve problems in the most general way possible. They tend not to be happy with solutions that are "good enough for now." Platonists are generally not inclined toward empirical or iterative approaches to developing software because they see software as something like a math problem - something to be analyzed completely and solved in its entirety. Joel Spolsky jokingly referred to the kind of people I'm talking about here as "Architecture Astronauts," which highlights their main weaknesses: Platonists can fall into the trap of spending far too much time trying to fully analyze something leading to the infamous analysis paralysis that software teams are often subject to. Platonists also tend to produce designs that are so abstract it's difficult to actually work with them. You know you're dealing with software designed by a platonist if it can theoretically do anything you want it to but it's hard to figure out how to make it print hello world. A good platonist is great to have around when you need to apply or develop a sophisticated algorithm. They enjoy most being set loose on an intellectually challenging but well defined problem. I think Peter Norvig is a platonist and of course Dijkstra was the original platonist!

The Communicator: Communicators think of software develoment more as human language designed for human consumption than as an abstract mathematical concept. They focus on expressing ideas clearly in code. Both tinkerers and platonists would tend to leave a piece of code alone once it's working properly, but to a communicator it's not good enough for code merely to be correct. It also has to be maintainable. Communicators can focus so much on the quality of their code that they might miss the point that a given situation calls for a well-defined algorithm. They also don't enjoy figuring out how to hack something just to make it work, which wether they like it or not, is often necessary. Another problem I've seen with this style of development is that communicators can become overly enthusiastic in their efforts to shape code, so instead of writing code that is concise and simple they wind up producing bloated class hierarchies and abusing design patterns. I think communicators may share this type of weakness with the platonists. Good communicators are great to have around as people who remove duplication from code and generally clean it up. They can be helpful in translating a sophisticated algorithm into code that can be readily understood and if there is some gnarly code in the system, they at least will write adaptors that encasulate that code behind a clean interface. Developers who are good communicators often work well interacting with users and customers to translate and organize requirements that may seem arbitrary and complex into code that is consistent and simple. Kent Beck comes across as a very prototypical communicator. After all refactoring, one of the main practices in XP, concerns itself with the idea of altering the structure of code without changing what it does. I think Martin Fowler is another good example of a communicator.

All three of these "personas" have some strengths and some weaknesses. Also if you find that you tend strongly toward one of these poles, it may be worthwhile to expand your consciousness a bit and to force yourself to develop in the other directions as well!