The carpenter has to assess and work with the variations of the grain, strength, and imperfections of the wood.

And he has to chose the tools and techniques he uses for any particular job to suit the requirements of the job. Mortice and tenon joints and glue may be perfect for building a cabinet, but would take far too long when erecting shuttering for a concrete pour, where nails are more cost effective.

The programmer has to work with and around data that may be incomplete, badly formatted, or just damned inconvenient.

Likewise, he has to choose his language and tools carefully, and work with the strengths and around the weaknesses and imperfections of them.

It takes skills knowledge and experience to make the raw materials approximate the design.

No matter how well designed and drawn the plans for a workpiece are done, translating the raw materials into the product is far more than just 'cut here', 'drill there', 'screw that'. How you cut, drill and screw means that two equally skilled practitioners of the art, or even the same guy on different days, can produce good and bad examples of the same thing.

The same analogy holds for programmers. How you choose to perform each step is nearly as influencial to the outcome as performing all the steps and doing them in the right order.

Carpenters, like programmers, are not machines.

Where a sheet metal press, or autolathe or grinder can be set up to turn out consistantly identical parts, each workpiece or program is created anew.

Even the best carpenter can have off-days. Cut in the wrong place or too deep; pick the wrong piece of stock; or misread the measurements.

Mass production methods can go some way to speeding up production and alleviate variance, but the final product is never quite as satisfactory.

Using engineered woods (plywood, MDF, veneers etc.), and automated machinery can allow for the production of cheaper products.

But just as a set of mass produced kitchen cabinets will never quite fit any given kitchen as well as the bespoke output of master carpenter. So the results of a 4GL; the mix'n'match of generic libraries; or the filling-in-the-blanks of a framework; program will never be as fit for purpose as one written by a skilled programmer to satisfy a targetted specification.

Basically, just as with carpentry, there is just as much art and craft in software development as there is engineering. Perhaps more so. That will have to change unfortunately.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Why? - threefold: why does it have to, why should it, and how could it? Carpentry is as long as things are made of plain wood. Yes, tools improve, power tools get invented - but the craft remains the same.

Why? - threefold: why does it have to, why should it, and how could it?

Simple. Economics.

There are still Master Furniture makers like Joseph Hemingway around, and most of us would love to be surrounded by the type of furniture he produces, but few people can afford to be so.

Software production costs way too much. The development costs are alleviated somewhat by the cheapness of mass distribution, but still it will have to get cheaper.

For the how, you need to look at better tools. In particular, a set of standards covering the interfaces for reusable, interchangable components (libraries) so that we programmers can bolt together more parts of our programs from them, more quickly and with less interfacing glue.

And there will have to be less languages. When I was growing up there were a dozen or more mass production car manufacturers in the UK, a dozen or so in France more in Germany. Now there are less than a dozen across Europe. And many of those are brand names owned by the same parent conglomorates. (Nissan == Renault; Volvo/Jaguar == Ford; Seat/Bentley/Bugatti == VW-Audi; Gone are Austin; Morris; Humber; Hillman; Roots; Vanden Plas; DAF; and many more.)

Consolidation is inevitable. As is automation. People have been trying to automate program generation since programming began. There was one pretty serious attempt made way back in the early '80s called The Last One. (Meaning the last program that would ever have to be written by hand.)

We know that it got no where, but it won't stop people trying. And eventually succeeding. There is nothing more suited to applying the power of computers to than the creation of programs. We programmers are applying the power of computers to ever more complex fields of endevour every day, but still insist on hand crafting our own endevours using a disconnected, non-interoperable set of tools that go back decades. That's the equivalent of corporate accountants and commodity traders still doing double entry book keeping using quills and ledgers.

C & Fortran compilers can already generate better optimised assembly code in the general case than an experienced assembler programmer can achieve. The Haskell compiler can basically take a mathematical description of an algorithm and turn it into extremely fast and robust code.

But most of use are still coding in a general purpose editor, then submitting our code to the compiler/interpreter for syntax checking. Then stuffing that into a text-driven source control database. And recompiling/interpreting the source code from text representation every time.

Sure, there are IDEs that will syntax check (some) languages as we type--but they are still widely eshewed. And we have object libraries, but they are in a different format and once created basically become static entities. Some compilers support pre-compiled headers and incremental compilation, but their databases are in proprietary formats and can't interoperate with each other, or other tools.

All of that has to change. And it will. Programmers have to start applying their art to their own works and tools. It's inevitable.

Personally I see it as more like a puzzle. You start by finding that easy, well-loved corner bit, and then you have to mix and match more and more of the puzzle until you have the perfect result. If one little fragment is missing, it is not perfect and may be misprocessed by others:).

The other option is seeing it as being like algebra. I once had an algebra teacher who kept telling me, nope, you can not start to solve the problem by finding the solution, you need to simply do the very first step, and then the next... Programming is exactly like this as you need to have each little element working perfectly before anything further will do so. In algebra, one incorrect calculation and the whole thing falls apart. In programming it is just the same.

These all sound like reasons why it's like engineering, which was my vote. Engineers have to work within the constraints of the materials available, they have use the available skills and knowledge, they are not machines, and mass production helps but isn't a cure-all.

And whilst there will be some variations in the strength, hardness and other properties of these materials, generally these are accounted for using pessimistic Safe Working Load (SWL) margins and quality control using automated processes.

By contrast, the carpenter has to individually inspect each 2x4 to check for the presence of knots or insect damage that can seriously degrade the performance.

In a few situations, the programmer has the luxury of specifying the format of raw materials (input files etc.), but more often than not he has to accept an existing format (XML, FASTA, jpg) regardless that it may be entirely inconvenient for this particular application. Further more, he cannot specify or predict the quality of the data.

they have use the available skills and knowledge,

These days, it is possible and very common place for non-experts to design components, and have software that converts those designs into CAD/CAM instructions that can be fed directly to automated machinery that manufactures it.

You can even do this via the internet! You download a free CAD package; create a drawing of the part you need; view it in 3D; specify the material (steel, brass, aluminium, plastic), Get a price estimate with one-click. Order it with another.

Imagine being able to do that for software?

they are not machines,

Actually, mostly they are machines. When I was doing my apprenticeship as a mechanical engineer 30 years ago, the production line for the average family car involved tens of thousands skilled & semi-skilled workers. Today, the same production line is run by a couple of hundred workers, mostly machine minders, logistics staff (who keeps the robots fed with parts), maintenance and quality control people. The rest is done by robots.

In other fields of engineering it is pretty much the same story.

Civil Engineering: Whether building a bridge or an office block or a ship, much of the raw materials and sub component assemblies are manufactured by automated machinery.

Electronic engineering: Electrical & Electronic components are produced in huge clean-room factories with environmentally controlled atmostpheres tailored to the needs of the machines and processes, not the occasional human inspectors who have to go through decontamination processes and wear protective suits to enter.

Chemical Engineering: Beyond the research labs, the processes involved are conducted in huge plants of tanks, pipes, reaction chambers and refraction stills. Monitored and controlled by computers. With the only human beings present being maintainance crews.

and mass production helps but isn't a cure-all.

30 years ago, the final finishing of car bodies was done by hand, 'wiping' the joints using molten lead. The paint was applied by a human sprayer. The final finish was inspected by a man with a bright light and a magnifying glass. Now all these processes have either been designed away, or are fulfilled by computer controlled robots.

The only thing in software that is anything like mass production right now is the production of distribution media.

Before software production can be called an engineering discipline, similar levels of automation will have to ensue. And it is already possible to some level.

Take the vast majority of commercial webs sites. They have a database of things; those things have attributes and a price; the user needs to be presented with those attributes and given a means to search, select and compare them. Once their choices are made, the prices needs to be accumulated, their delivery and payment details collected, payment arranged and verified. Delivery arranged and tracked. E-bay, Amazon and GoogleShopping have already automated most of this.

The same can be done with most other types of website. Facebook et al. mean that there is no need for most people to program their own 'homepage' anymore. With Google:Blogger|Groups|YouTube|Gmail|Calander|Docs, and their competitors, the question becomes what to share, not how.

With the advent of the Google browser and the Google Web Toolkit, how long before designing a new website for just about any purpose becomes a point'n'click, drag'n'drop affair that takes care of the DB schema, scalability, validation, authorisation etc. and just leaves the 'programmer' to decide what questions need to be asked in what order and what pretty pictures and fonts to use?

There will be some hold outs. The banks will continue to design their own, usually awful applications. The big traditional retailers will continue to have in-house software development teams. In the same way they continue to have their own trucking fleets, even though it would make economic sense and be greener to have a single distribution network for all of them. What sense does it make to have all the big supermarket chains sending their own trucks to each of the producers of breakfast cereals, to pick up the same produce?

Software production will become an engineering discipline, but it isn't even vaguely one yet. And most of the so-called software engineering processes, are as akin to modern engineering processes in other fields, as the blacksmith shoeing a horse.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

We'll have to discuss what 'engineering' means over a pint of beer sometime -- I don't have time to write out a complete response to your excellent answer.

In a nutshell, though, engineering is applied science. Science includes investigative tools like the Scientific Method, and the idea that the Scientist or Engineer is always learning by reading technical publications and interacting with other professionals. Naturally, this activity includes Perlmonks. which I will say with a straight face is Professional Development.

Jeepers -- after 11pm and you've made me want to write a long dissertation about it.

What then of 'craftmanship'? What does that mean? To me, that means a deep understanding of what you're doing, a knowledge of the available techniques, resources to fall back on, and the ability to build a suitable solution that is clean, perfect and documented. Oh, and the work should be good enough that the craftsperson is proud to show off their work to other professionals. I strive to write code and documentation that good (and I am working towards learning how to write decent tests as well).

Finally, developing a web site is rarely a cookie cutter operation -- just try and develop web sites for a living. It's brutal -- no two are alike: a template will only take you part way.

People with no aptitude for carpentry tend to have a few minor but painful slips early on which convince them that some things are better left to those with a greater aptitude.

Unfortunately, incompetence in programming does always effect such a change in attitudes.

That's not to say that programming tools can't be abused. From people using Word as a program editor; to programming editors that evolve to be close to stand alone operating systems; text macro libraries that are so entirely opaque as to defy understanding; to make files so complex that they start to exhibit signs of Heisenberg Uncertainty; to 'simple' configuration mechanisms wrapped up in unfathomably deep OO hierarchies. The list goes on.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other