Blaine Buxton: Positronic Vibrations From Alto Dorado

Clerical Programmers vs. Artist Programmers
This article was inspired by discussions on the lightweight languages list and an article called "Hackers: sketchers, drafters". The discussions started off with an article that blasted XP as lacking in real software engineering practices. You can find that article here. Now, I do think XP can be taken to the extreme in this article, but in reality, what happens is that "you do simplest possible thing now with an eye to the future". This means you still plan and scope, it's just that your deliverables are smaller and you spend less time working out ALL of the details which is where a lot of people get lost in more rigorous software engineering practices. You just need to plan to be "good enough" which is fine for most business software. But, I digress because this article is not about defending agile processes. No, I was shocked into writing this article because of the "Hackers" article. Now, you might ask me why did this article shock me? I liked the article a lot and thought it was a nice contrast between two different types of programmers. It described both very well, but it was the following statements:

"Clerical programmers are often much less apt at solving tricky problems, and will not know what to do with the freedom given by things such as dynamic typing. If given too much freedom they will likely end up using it inappropriately and be found having created a mess and coded a project into a corner. On the other hand, they can take a tedious but well structured task and happily plug away at it. They often have no need to have their code admired, in fact they may prefer it remain unseen.

Clerical programmers should work closely with other clerical programmers. In fact, they will often enjoy the company and dynamics of team programming.

In short clerical programmers are great for large tedious and exacting projects, projects that are not inventing new types of wheels. They are well suited for the database logic somewhere deep within the back recesses of a company, or creating an endless number of simple and routine web systems--taking large but programmatically simple requirements and working tirelessly at implementing them. "

These statements assume two dangerous things: Clerical programmers are not bright and business programs are easy. Neither could be farther from the truth. Sure, business applications are not inventing any new wheels, but the thing that makes business applications hard and difficult is that they are trying to capture years of convulted logic and processes. Years of contracts, legalities, compliance, new products, etc make the business landscape very rocky and difficult to traverse. Typically, the hard part of business applications is simply capturing this logic. This simply can not be done totally up front and designed to the nth degree. This is where XP comes in because you design for what you know now, but try to plan for what might come up. Now, in any business application, no one can predict what pandora's box might be opened during coding. Thus, the need for short deliverables and constant refactoring as you find out what you knew yesterday is wrong. If you try to this planning up front, a lot of these boxes remain unopened because writing code that works forces them open. The point I want to make is that writing business software is difficult because there are no rules. Game developers have physics to rely on and drafters have geometry. Clerical developers do not have the same luxury. Artistic programmers usually program in a bubble that is in their own world much like real artists. But, the artistic programmers are usually more willing to try new things to do in business applications to solve problems and are thus, an asset to the business application team as well.

I also took offense to saying that clerical programmers could not handle a "dynamic typed" language. Well, I worked in large companies with dynamic typed languages like Smalltalk with clerical programmers. These programmers usually "got it" and were way more productive than programmers using "static typed" languages like Java. I generally like to think that one should never be scared to give features to programmers because "it might too advanced for them". I have found give them the advanced features and sure, some folks will not use them, but a few will. And those few are your most productive programmers. If you take away features that make them productive, then everyone suffers. The projects that have been on that have used Java are way less complicated than any of the projects that I worked on in Smalltalk. Most of the Smalltalk applications had domains of 1000s of objects where in Java, the most complicated domain that I have worked on is in the 100s and they have generally taken longer to develop. Now, I do not want this to be "static" vs. "dynamic" typed language argument, I think the Smalltalk environment is what makes it the winner here and not that it is "dynamic". I simply wanted to make the point that if you give developers the right tools and not worry whether it's too much for them to understand, then they will be more productive and make less mistakes. So, sure most of the places I worked in Smalltalk, the programmers didn't worry about the meta-object protocol and they didn't have to. But, the most advanced programmers did dabble in it and sometimes worked productivity gains for everyone by playing with it. I think this is a win and why would you not want this?

My main point is that don't assume business applications are simple just because they are simply moving data. There's a lot of convulted logic that knows no rules to get in the way. And also don't assume that clerical programmers can't handle the features that you would reserve for artistic programmers. Both can enjoy and get productivity gains from those features. Never assume that your users are too stupid to understand a feature. Well, that's all I have to say about that...=)

posted by Blaine at 8:53 PM |