[pkorzeniewski]

Who cares which language, library, framework, tool etc. are you using? Just get the job done! There is no "ultimate" solution. Software developers tend to attach too much importance to tech stack - in most cases it just doesn't matter, as long as it works.

[TeMPOraL]

This attitude leads to a world full of crap, where everything crashes all the time and is slow like hell, while still costing megadollars.

We don't ask doctors, plumbers or auto mechanics to "just get the job done". We ask them to do it right.

[snowwrestler]

Doctors and auto mechanics routinely use tools and abstractions that they don't fully understand. (Not sure about plumbers.)

For example how many doctors know how a CAT scan works? They trust that the machine is doing its job correctly, and focus their expertise on interpreting the results. And a lot of auto mechanic work today involves reading codes off the car's electronics and looking up the fix. Do you really think every auto mechanic understands the full hardware/software stack of all the cars they fix?

Abstraction is not a problem; it is a productivity multiplier. But only if it is done right.

The biggest problem with software abstractions these days is that their quality is so low that they can't be trusted. Imagine if CAT scan machines were built to the quality standards of Django or RoR. People wouldn't stand for it.

[adricnet]

Actually the entire point of professional education and training, then certification for roles such as those you cite is that they must have an understanding of their tools and the principles behind their use. They are also intended to keep that understanding up to date throughout their careers and the continuing education requirements of licensing support that.

The difference between a repairman and a mechanic, in classical terms, is that a repairmen fixes things with tools someone else made, and a mechanic can make tools. They must understand how machines and tools work, and a doctor (of medicine, a physician) is supposed to have general knowledge of the functions of the body, of the diseases and ailments that effects, and the technology currently available to try to help.

In the Django example up thread (or typical newbie Rails app, etc) an "app" is quickly spawned that the dev may not how to secure, update to new requirements, internationalize, or make perform fast enough to useful.

Somewhere in these mixed metaphors is a discussion about the difference between programming, computer science, and software engineering ..

[jasonwocky]

> For example how many doctors know how a CAT scan works?

I don't know. Do you? Or are you just assuming that most of them don't?

[TeMPOraL]

My brother just went to study medicine; they didn't get to CAT scans yet, but from what I saw he's learning about ECG, he is expected to understand the physics and math behind it on a basic level.

[snowwrestler]

Doctors definitely understand how CAT scans work conceptually, to the extent needed to interpret the results, including whether or not the results are valid. They don't know, and aren't expected to know, how to build one, or open one up and fix it.

[rip747]

"We don't ask doctors, plumbers or auto mechanics to "just get the job done". We ask them to do it right."

We're building software here, not saving lives or building something physical. Software is virtual, it can be refactored and fixed numerous times until the desired performance and bugs are all worked out.

Doctors and anyone building something physical don't have this luxury. You can't tell a doctor to "refactored" a heart transplant so they have to get it right the first time.

[collyw]

I aggree. I also think there are magnitudes of difference in time and effort required to build a "script that works", and "reliable software".

[jff]

Tell that to the healthcare.gov people.

[mogosselin]

When working on big applications (> 1 million), this wouldn't work. You need to think about it and you need to know how stuff works.

[JacobH]

But then again, a big application has to start off as a small application. Once you get to the large state, you are simply just swapping out bad components for good.

[protonfish]

This reasoning only holds if all technologies are equally good and all lead to rapidly building stable, specification-correct and easily maintainable applications in all situations. Sadly this is not the case - poor development happens much more frequently than not and we should constantly be examining our tools to understand why and to improve our work.