It's a Tool, Not a Religion!

One of the great things about sitting in traffic is you get to ponder various things. Recently I was contemplating the ongoing debate about REST vs SOA. Last week I was involved in discussions on C++ vs Java. Last night I stumbled across some debates on Django vs Rails. It occurred to me that software engineers are unique within the technical world. Rather than rejoicing in a rich toolbox, we argue over its contents, hoping to discard all but the smallest possible set.

One of my hobbies is British cars. We have two in our garage which means that either I learn to work on them or go broke paying mechanics. So, I participate on discussion lists related to them. Occasionally somebody will suggest a unique application of a tool to address a difficult issue. If others have found alternate approaches, they'll share those ideas, usually involving a different tool.  I have never once, in more than a decade of participating in these discussions, seen an argument erupt over whether one tool or the other was the singular correct approach. Sure, if the tool was completely inappropriate and might actually result in damage to a component, there is a discussion. But as a whole, mechanics don't argue whether the open end or boxed end of a wrench is the single correct end and should be used to the exclusion of all other wrenches or sockets in existence.

I also have several friends running contracting companies. I have spent time around job sites. I can promise you that you'll find circular saws, chop saws, and table saws. Is there overlap in functionality and potential application of these saws? Absolutely. Why have all three then? Well, because each is particularly good for certain types of cutting chores and less optimal for others. Contractors, like mechanics, want a broad set of tools available so they can have the optimal tool for each task.

Why then do we, as software engineers, have to work so hard to reduce our toolbox to the ultimate tool? There is this tendency to look for the Swiss Army language with supporting framework that will be the optimal solution for every problem in the world. The simple reality is that such a language and framework can never be created. Why? Well, engineering is always about compromise and the compromises are intended to optimize the solution along certain paths.  If your problems lie along that path, then the tool will be perfect. If not, well, you have a sub-optimal tool.

I'm ecstatic to have a rich set of languages and frameworks available in my architectural toolbox. The shear breadth of the problems that we face everyday makes it important to have options available. Understanding these tools and there applicability to any given problem should be the job of architects.  There are plenty of hard problems that need attention. Spending energy trying to denigrate or eliminate viable tools is pointless.

Technorati Tags: architecture, engineering, programming, rest, services, soa, software, to_read, toread

Comments

[pongba]

I disagree.
If programming tools are such things that can be picked up readily and used immediately and thrown away afterwards, then your argument probably *is* right.
But they're not.
It normally takes one from a month or so, in the case of most dynamic languages, to ten years, in the case of C++, to grasp a programming tool(technique) well, not even mentioning to be an excellent programmer or architect.
So, what does this suggest? The thing is, the learning curve makes individual programming tools special, not only with respect to the innate strength, to the money and face, too.
The most important thing, however, is that people tend to make the thing they're really good at look good, because that will make themselves look good!

[dexev]

I think you're drawing the wrong automotive analogy. Programming languages != wrenches, they == models of cars.

You said yourself that English cars are a hobby of yours. VW's are one of mine. I wouldn't want to work on your cars, and the reverse is probably true. The Ford/Chevy wars are at least as raucous as any C+/Java debate I've ever witnessed.

[pexer83]

I agree that learning to use most common mechanical tools (screwdrivers, wrenches, saws, etc) is easier than learning software tools. It does take some time to learn Perl Regular Expressions, or other complex tools. I agree that there is a lot of time invested in learning these tools. (I also agree that the feud between Chevy and Ford lovers can be very fanatical. I'm a Chevy man myself. :) ) Not too mention Engineers are constantly having to prove their ideas which can carry over in their attitude towards other Engineers.

However! Has anyone ever tried to build a really nice looking chair? One with a lot of curves and designs etched into it? Learning to be a master furniture maker takes a lot of years of experience. Years of practice with the right tools (notice the plural usage). I have friends that do this and they are not fanatical about the tools they use. They just know that to get a certain job done, they use a certain tool. This is what I believe Dan is talking about. Good Architects do not need to be Guru's at all the tools, but they do need to be Guru's at knowing which tools to use to get the job done. Having a "breadth" of knowledge that spans many tools is what makes a good Architect. Having a "depth" of knowledge about a tool is what makes a good Senior level Engineer with design skills. (There is a difference between the two types of people.)

In my opinion this article is about Architecture more so than Development. In my 10 years of experience, I have come across people who claimed to be "Architects" and touted certain tool sets that did not really fit the job. This is mainly due to the fact that they are using Resume based Architecture; instead of Open Minded Simplistic Architecture.

[Leshek]

To some extent I agree. But...

If you have tools scaled in millimeters, you may damage the components measured in inches, and that is from the technician level, from the architect level we deal with components build with different units of measure... a bigger problem when we want them to work/interface with each other.

With software components is more like in a spoken/written language. You need to speak the common language to communicate.

Now... there is google translator. There are software, services adapters.. but... that is not simplicity when you need to add those.

Well.. go figure we do :-)

[Jeremy Dunck]

To avoid using Crystal Reports back in '98, I rolled my own line-oriented reporting tool in VB.

5 years later, I needed the same thing in Java. I translated the VB one to java in one day.

I'm sure I introduced some bugs in the process, but yeah, it'd be nice if there were a lingua franca. Python (my current dayjob tool) has a great interop story, but then you hear (and feel) the idiomatic impedance.

There's no one right answer, and design -is- about compromise, and it's all one babel'ing shit sandwich. But until I get the head jack with the 30 second download of my choice of J2EE, SICP, or SOAP, well, I'll stick with the tools I've already spent years learning. And maybe pick up a few that look especially useful.

And ignore the ones you don't. And regret the lost opportunities of the disconnection of the network effect. Oh, if only there were only one tool that everyone could work on...

Getting the picture?
http://www.amazon.com/Wealth-Networks-Production-Transforms-Markets/dp/0300110561/

[Damien]

You sir, are my new Messiah.

[pinto]

Your comparison seems to suggest that spiritual tools (religion), unlike software and auto tools, must be inflexible. Why exactly should this be so? I tend to feel that religion always comes up in this context since it's a category of disagreement that's hard to resolve. Like politics or geek turf-wars. One of those things where people get sick of listening and just want to walk away from the battle. Better still if they can walk away with a sense of moral superiority.

Moving on to your actual point, there's a difference between using different tools for different jobs and deciding on the best tool for a given job.

We don't write web apps in assembler and we don't write embedded hardware controllers in ruby. But we do argue over RISC and ruby vs python.

This is as it should be. It's probably a good idea to get some exposure to many languages, but learning any language to a master level is a huge time commitment. Learning Django and Rails at that level would be a duplicated effort and a waste of time. As a result, comparing them is a valid concern. Your analogy just doesn't hold, since it doesn't take years to learn how to use a wrench.

[Dan Pritchett]

There's an interesting theme emerging which is contrary to my point of view. The argument is that the tools are not a means to an end but the end themselves. I've always viewed what I learned from a new language or framework as skills that made me better at software, not the tool. So time invested was always productive, even when I moved onto other tools.

History is a pretty good instructor on this topic. Pick a decade since 1950 and identify the top development tools of the era. Now go back to the 1990's and identify how many tools are still in widespread use as we close on the end of another decade. Software tools have a 10 year life span on average, really good ones might survive 15-20. Fanatic commitment to a single tool will pretty much define the length of your career in this industry.

The Dean of my computer science department told the freshman class (way back in 1978) that if we weren't prepared to reinvent ourselves every 5 years, change curriculum now. That was potentially the most important lesson I learned for my degree. He was right way back then and he's still right.

[Paul]

The fundamental reason that developers are passionate about their tools is because unless they are senior architects they often are not allowed to select them. I actually am a team lead and could (in theory) choose my language, but I'm stuck maintaining code that someone else wrote. I decided it was too risky to rewrite in the time available: that means that my whole team is now required to use the suboptimal technology for the time being. Using suboptimal technology means less productivity now and a rewrite later. Because our team is dedicated to efficient results, this is very demoralizing.

Precisely because programmers disagree so intensely on what features of a programming environment are key, hundreds of thousands of programmers are stuck in this position every day. I wonder about the morale of the programmers at eBay who probably tried to convince the dev management to switch to Java a couple of years before they did so. It is quite conceivable that they spent two years programming in a language that they considered inefficient and ineffective and then another substantial period rewriting in the language that they wanted to use in the first place. Life is too short to waste using wrong (or poor) technology. That's why people are passionate about driving what they consider to be poor tools out of the industry. As long as they are in the industry, we are under threat of being asked to salvage code created using the "wrong" technologies.

[Paul]

"Fanatic commitment to a single tool will pretty much define the length of your career in this industry."

That's a strawman argument. There are very few people out there who will argue that ONLY REST or Rails or Haskell or JSON is worth consideration.

The religious wars arise because there are people who specifically believe that WSDL or PHP or Java or XML is either NOT worth consideration or vastly overused. The uber-activists are not trying to limit options to their favourite language. They are more often trying to curtail use of a technology that they consider obsolete or ill-considered. Ultimately, the industry progresses through the simultaneous adoption of new technologies and the abandonment of old ones (for some particular problem domain). It isn't enough to say: "Java is a good language for Web application development." You will only make progress by contrasting with that which preceded it, and eventually causing a paradigm shift in the Kuhn sense.

If you think of theories as tools for the advancement of science, and programming tool advocacy as theories about which tools are most efficient then it is not surprising that these paradigm shifts should be contentious and disputed, just as in science.