in reply to Programming Versus Engineering
in thread (OT) Programming as a craft

A homeowner hires a carpenter to build some kitchen cabinets and they come out really nice so the homeowner asks the carpenter to design and build a housing development. Me, I'd prefer to have an architect and a planner involved. Can the architect or the planner build kitchen cabinets? Probably not. The carpenter is good at the specifics and might or might not know something about the big picture and the architect is the reverse.

Some programmers are like carpenters and some are like architects, but most I know burn the candle at both ends - we like to think big and plan out all sorts of swell high level object manipulations and software interfaces but we also take pleasure in polishing off the corners on the indents and the idioms in the code itself.

But society doesn't like these things mixed. According to THE RULES (sorry, I lost the URL for the rule book) the specifics should be left to the low level drones. Higher level managers should only concern themselves with the big picture. This means that programmers get treated like craftsmen regardless of their skill level and managers ignore the programmer's planning advice as too specifics-oriented to be real planning.

Replies are listed 'Best First'.
Re: Re: Programming Versus Engineering
by chromatic (Archbishop) on Dec 16, 2003 at 06:05 UTC

    I'm not sure I follow your analogy.

    Craftsmen build things? Non-craftsmen don't build things? Craftsmen don't plan? Architects aren't good at specifics?

    What if you hired a painter to design your housing development? Would he be as bad at it as your carpenter might be because a painter is a craftsman? Can an architect not be a craftsman?

    Let me be specific: I believe that the source code is the design. Compiling is the manufacturing. Engineering is, what, measuring the tensile strength of a stable quicksort algorithm?

      Yes craftsmen design things, but the nature of what they design is different from what engineers design. A carpenter is expected to be good at designing and creating objects like cabinets and doors, using primarily the single material of wood and a few screws. If the carpenter is also good at designing and creating complex multi-object, multi-material things like houses and housing developments, that's cool, but it's not something we'd assume from knowing they are a carpenter. Some architects can build cabinets, but that doesn't neccessarily relate to whether they are good architects or not.

      A webmaster who has become proficient at CGI scripts to do simple tasks might also be able to design an enterprise-wide software strategy, but it's not something we'd assume from knowing they are a webmaster. Most of us here at the Monastery can take potshots at particular bits of how PM works, but it's gods like you who have the whole picture.

      An engineer is someone who understands how a complex group of things built from a diverse set of materials work in conjunction with each other and who is capable of designing and planning a system that will safely perform the functions it needs to. I'd say some programmers could be described the same way.

        Okay, so if the important part of being an engineer is the safe design and synthesis of an object as a whole from diverse materials, then a general contractor is an engineer while a carpenter or a drywaller isn't.

        If I were nitpicky, I'd ask if a semiconductor engineer were really a craftsman, because he's expected to be good at designing and creating chips, using primarily the single material of silicon and a few transistors.

        I think what you're really trying to say is "Engineers design complex things and craftsmen don't." That's a fair opinion. I completely disagree, but I think it's much closer to your opinion than the silly metaphors I dragged you to. :)

      Let me be specific: I believe that the source code is the design. Compiling is the manufacturing. Engineering is, what, measuring the tensile strength of a stable quicksort algorithm?

      I think it is a serious mistake to equate code with design. Granted, an agile methodology intermixes design and coding in an iterative and mutually informing process, and the final code (and documentation) may be the only tangible artifact produced, but that still does not mean the code *is* the design.

      As for engineering, yes there certainly is engineering in software development, running the gamut from the ad-hoc or experiential engineering that any builder / tinker / craftsman etc might display, to algorithm analysis, to the design of language features that increase assertions of correctness (within particular domains of correctness).

        I think it is a serious mistake to equate code with design.

        Why?

Re: Re: Programming Versus Engineering
by revdiablo (Prior) on Dec 16, 2003 at 18:37 UTC

    I think this is what I was getting at. I get the sense that the different types, maybe they can even be called factions, of programmer are slowly diverging. I'm not a historian, but I have an inkling that this mirrors similar trends in any newly emerging industry.

    There is a difference, though, that it seems chromatic has been trying to articulate: software plays by different rules, because it is not tangible. It's generally not practical for the person drawing the designs for a housing tract to actually build the houses, but with software, the code is the design. The design and the implementation are essentially the same thing. Sure, people have come up with many methods of planning and designing software before the code is put in place, but at this stage in the game the code is the blue print. The planning and design that goes on in the software world is very general and high level. The true design, in the real sense of the word, is in the code.

    I think this might change in the future, as we keep going higher and higher level, but even then it won't be the same as with physical production. The intangible nature of programming just makes it different. Perhaps I am undermining my own analogy here, but I think, in the software world, engineers and crafstmen can be one in the same.