I disagree that programming is "more than a craft". No, I think the craft analogy for programming is quite appropriate. In fact, I am of the opinion that much of the absolute and utter failure of so-called software engineering to deliver meaningful improvements in programmer productivity has been due to its repeated failed attempts to apply engineering discipline to what is essentially a craft problem. After all, we don't have "wood engineering" for carpenters and cabinetmakers. We don't have "fabric engineering" for tailors and dressmakers. Engineering principles are designed to solve known problems in a reliable and repeatable manner. We understand that cabinetmakers and dressmakers don't deal with the same problems (or necessarily even the same sort of problem) day in and day out. That's why we don't apply engineering principles to those positions. So why do we insist on applying engineering principles to programming?
Designers aren't asked to come paint a house. Accountants aren't asked for stock tips. Someday, programmers won't be asked antivirus questions anymore.
Those are bad analogies. Like it or not, antivirus software is significantly more closely related to programming than, say, house painting is to design. Better analogies would have been, "Surgeons aren't asked questions about dermatology. Divorce lawyers aren't asked questions about tax law." Except, that's not true, is it? People do ask surgeons questions about their skin lesions, because, "Hey, a doctor's a doctor, right?" People do ask divorce lawyers tax law questions because "Hey, law is law, right?" And people will continue to ask programmers about anti-virus software because, hey, computers are computers, right?
Comments
I disagree that programming is "more than a craft". No, I think the craft analogy for programming is quite appropriate. In fact, I am of the opinion that much of the absolute and utter failure of so-called software engineering to deliver meaningful improvements in programmer productivity has been due to its repeated failed attempts to apply engineering discipline to what is essentially a craft problem. After all, we don't have "wood engineering" for carpenters and cabinetmakers. We don't have "fabric engineering" for tailors and dressmakers. Engineering principles are designed to solve known problems in a reliable and repeatable manner. We understand that cabinetmakers and dressmakers don't deal with the same problems (or necessarily even the same sort of problem) day in and day out. That's why we don't apply engineering principles to those positions. So why do we insist on applying engineering principles to programming?
Designers aren't asked to come paint a house. Accountants aren't asked for stock tips. Someday, programmers won't be asked antivirus questions anymore.
Those are bad analogies. Like it or not, antivirus software is significantly more closely related to programming than, say, house painting is to design. Better analogies would have been, "Surgeons aren't asked questions about dermatology. Divorce lawyers aren't asked questions about tax law." Except, that's not true, is it? People do ask surgeons questions about their skin lesions, because, "Hey, a doctor's a doctor, right?" People do ask divorce lawyers tax law questions because "Hey, law is law, right?" And people will continue to ask programmers about anti-virus software because, hey, computers are computers, right?