« Call to Action, The Case for HTTP Headers with SOAP | Main | You Call it Coupling, I Call It Reality »

Wednesday, December 13, 2006

TrackBack

TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d83456008969e200d8342c738e53ef

Listed below are links to weblogs that reference It's a Tool, Not a Religion!:

» Ultimate tool vs. Optimal tool from Steven Yong's Weblog
Which IDE is the best?With plugins, both Eclipse and NetBeans can compile and run Java programs, can draw diagrams, can be used as a database client, can hook up a server, and can even building C++ or PHP programs.Which C++ programmer would use NetBeans f [Read More]

» Day of the Dove from Pete Lacey's Weblog
Do you remember that Star Trek TOS episode where a hyper-intelligent shade of the color red locks a Klingon crew and the Enterprise crew in unending violent combat so that it can feed off their heightened emotions? Remind you of anything? If the RESTa... [Read More]

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.

The comments to this entry are closed.