Static vs. Dynamic: take 12,374

I heard it yet again at the No Fluff Just Stuff conference the other weekend: the classical debate between dynamic vs. static languages. If I hear this debate one more time, I swear I'll tear my own eyes out. So, just to confirm my hypocrisy, I'm blogging about it (and worse yet, you're reading it).

The trigger event for my fit of epileptic rage that resulted in the brain-dump you are now reading was the expert panel. Someone was malicious enough to bring up Ruby and people regurgitated all the same arguments that we've been using since the "Perl vs. C/C++" debate:

"Use the right tool for the right job..."
"Dynamic languages just need lots of unit tests..."
"But people won't write unit tests..."
"Those people are stupid..."
"What about refactoring?"
"Look how little code you have to write..."
"But it's hard to read..."
"Yes, but if it was hard to write, it should be hard to read..."

One person, however, did say something that got me thinking. He said, "I would use Ruby on a project where it was me and four of my closest, well trusted friends who share the same level of coding standards that I do." This is when it clicked. I would love to work on projects like this. But currently, I am stuck writing code on a large project where classes routinely go beyond thousands of lines, copy-paste is confused for code-reuse, and HashMaps get used as a poor man’s version of a C++ struct. On top of that, I have no control over who I work with (this should be obvious from the previous statement) much less who will be maintaining this lump of code a year from now.

Beat that horse…

Ok, now bear with me while I beat a long dead horse one more time (new horses are hard to find these days). Let's compare the software industry to the construction industry. I'll bet anyone in the construction industry would have more fun building a club house in the back yard for their kids than they would doing the electric work in a skyscraper. The reason is simple. A club house is a small project that would be over too quickly to get bored, would have a variety of work (roofing, carpentry, foundation, painting), and is small enough so you can wrap your mind around the whole picture. Running the electric for a sky scraper on the other hand, is boring. Day in day out for several years, wire after wire, never really being able to comprehend the full scope of the project.

But do you think they go home at the end of the day thinking, "Man, the backhoes and power saws we use at work suck, I'd much rather be using the hammer and saw I used on that club house"? In this case, it is the type of work, not the tools involved that make the project bearable or unbearable. (Although not having the right tools can make a project unbearable.)

So the question is: How much is it about "liking" or "disliking" Java vs. Ruby, and how much is it about liking the types of projects where Ruby is the appropriate tool vs. liking the types of projects where Java is the appropriate tool? Like Pavlov's dog, you can only get clubbed and beaten so many times with Java code on your screen before this code will make you flinch:

public void setSize(int size) {
this.size = size;
}

public int getSize() {
return size;
}

But this blog isn't about which language is better, or even more fun. It's about the paradox of power.

Ok, ok, here is the paradox...

The paradox is this: The larger the project, the LESS power your tools should have. Let's go back to the previously re-beaten horse and give him another whack: the analogy of software engineering and the construction industry. In the construction industry, the larger the project, the more power your tools need. If you are building a dog house, you need a saw and a hammer. If you are building a high rise office building, you need hydraulic cranes and bulldozers. This seems fairly obvious, but the opposite is true in the software industry.

In the software industry, the larger, the project, the more the tools should constrain the builders. The key difference here is which team members are able to use the tools. In a large construction project, there are bulldozer drivers who operate the bulldozers, and there are crane operators to operate the cranes. You wouldn't allow the brick layers to play with the bulldozers, or your liability would go through the roof.

We don't have this option in the computing industry. Instead, you pick a language and the whole team uses it. You can't say things like, "only senior developers can use closures," or "you have to have training as a software architect before you are allowed to use aspects." While that would be nice (I smell a new programming language coming...) the truth of the matter is that anyone on your project who can type a syntactically correct aspect can accidentally plant a major time bomb on your software project.

For those of us who have resigned ourselves to our fate of working on large projects in the enterprise where we have little or no control over who touches the code, we cling to the rigidity of Java. For those of us who are fortunate enough to work on small projects with trusted colleagues, we revel in the freedom of Ruby.