http://www.perlmonks.org?node_id=710113


in reply to Re: Programming is more like:
in thread Programming is more like:

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 there's most definitely craftmanship in engineering.

Alex / talexb / Toronto

"Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

Replies are listed 'Best First'.
Re^3: Programming is more like:
by BrowserUk (Patriarch) on Sep 09, 2008 at 22:27 UTC

    Not really. Or at least not in most engineering fields.

    1. Engineers have to work within the constraints of the materials available,

      These days, in many fields of engineering, we have reached the point where we engineer the materials to suit the application.

      For example, we can choose from a vast range of types of steel. Or use aluminium, magnesium alloys, titanium, carbon composite or any of a vast range of plastics.

      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.

    2. 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?

    3. 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.

    4. 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.

      Alex / talexb / Toronto

      "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

        We'll have to discuss what 'engineering' means over a pint of beer sometime

        I'll offer the following distinction between Engineering and Art&Craft.

        If you can draft a design specification for a product and then send that to companies in (say) the US, Germany, South Africa, India, China & Japan, and receive back 6 functionally identical and interchangable parts, then yours is an engineering discipline. Otherwise, it is at best an art or craft.

        Whether it is a car part, or a bridge stay, an MP3 player, a spectacle lens, a prescription medicine, a food additive, a size 9 slipper, or a reel of 3-core, 5 Amp electrical cable. All these can be manufactured to and tested against a specification alone. These engineering disciplines have the nomenclature and standards to allow this.

        There is not (yet) an equivalent for software.

        Musicians have a pretty well honed and universal nomeclature, but send a piece of sheet music to 10 different musicians and you'll get 10 different interpretations of it back. Even the same musician will play it differently, on two different occasions, and neither need be 'incorrect'.

        Even a simply specified software component like a sort, has a million variations. Even if you specify a quicksort, should it be in-place or copying? How should it handle nearly sorted input? What if the dataset is larger than memory?

        Look at the back of your user manual for your TV, fridge or mp3 player and it probably carries a specification of max and min working temperatures; max & min input voltages; EM radiation limits; and dog knows what else.

        What "spec and guarentees" does software carry?

        THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

        In other words: "It don't matter whether you paid good money for this or not, it may not work at all, or it may fail, with possibly fatal consequences, at any time, and we deny any and all responsibility or liability."

        Which in turn, is tantamount to saying: We don't give a flying F whether you paid us money or not, we don't give a flying F whether this works right, or kills people.

        You wanna talk about "professional"?

        <side track> Until programmers, individually and collectively, are prepared to warrenty, and take liability. for their code, the terms "professional" and "engineering" should not be associated with "software".

        I almost added, "copyright" in there, but you are not allowed to copy even bad books and music, so that doesn't fly.</end aside>

        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.

        Please excuse my use of the idiom, but I was so not describing a "use a template" process. If you followed (and read:), the link to 'The last One' I posted earlier in this thread (there is a lighter description here), then you'll get some idea of the kind of thing I am envisaging.

        RubyOnRails has shown that many web apps can be created by mix'n'matching a few well designed and written library routines. Imagine a fairly sophisticated Q&A-style, interactive front end that generated the RoR code. It generates the CGis, the schema, the queries, and some barebones html&javascript to get you up and running. All the business logic is generated according to the answers supplied. You then skin the generated html to provide branding and specials.

        Now imagine the GWT underlying the GWebDesigner(TradeMark Pending :).

        It doesn't exist yet, but I predict it will before decades end. And within 5 years there will be a GWebDesigner Certification Programme and the vast majority of web apps will be built that way. And will run in the GCloud(TMP).

        Sure, the banks and major retailers will hold out, writing their own, usually awful web apps. And the premium brands, like Ferrari and Gucci et al. will continue to pay through the nose to have 'view only', functionally useless websites designed by 'art house' programmers. But those who want functional, usable, scalable, affordable web applications will employ a certified GWeb programmer to develop them.

        There will still be the place for the Master Programmers. You know, those guys that we all admire and aspire to become. The ones that seem to put together 10 lines of code in half the time, that does twice as much in half the time. And they'll be the ones writing the programs that generate the tools that the rest of us will use to design and generate applications.


        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.