The Implict Assembly Line

George Lakoff in his book "Metaphors We Live By", notes that we model our conceptual system on metaphors but are often unaware of how they shape our thoughts, speech and acts. In other words, we use one concept to explain, understand, articulate, and work with another concept.

For example, one metaphor that is very pervasive is "Argument is War". We use war as a metaphor in thinking about argument. Witness, "He won that argument" "His criticisms were on target", "I destroyed his argument"

The point George Lakoff makes is that argument really doesn't have much to do with war, except that we make it so by choosing war as an analogy. For example, argument could be (but often isn't) a "joint search for truth" or a "game" rather than a form of abstract combat with winners and losers. Changing the underlying metaphor may change how you see something.

Once upon a time (but somewhat passe these days)the underlying metaphor for software development was "constructing a building (or bridge)" from which we still have "architects" and "engineers" , UML "modeling", and so on.

These days there seems to be a shift of metaphor. The underlying metaphor for much discussion on software development seems to be "Software Development (of the services variety) is an assembly line process".

The so called "Lean Development" (or "lean agile" or whatever the fad du jour is) talks about "pieces of work" being "flowing" through a development "pipeline" and endeavors to "reduce cycle time" through "kanban" using the "Toyota Production System".

Using this metaphor, software developers become equivalent to assembly line workers which managers or methodology experts "optimize". You can work on a "good" assembly lines like Toyota, where you have a degree of freedom to tinker with some of the details or a "bad" assembly line (uhh Wipro maybe? ) where you endlessly perform the same meaningless motions forever.

There are "kanban" or "lean" or "agile" experts out there who will "advise" you on how the assembly line should work, but will never work on an assembly line themselves! The assembly line worker doesn't have any choice on what he will work on, how long he will work on a particular assembly line, practically never comes into contact with a real customer (at best there is a "customer representative" or a "usability expert"), is relatively easily replacable. "Requirements" from an analyst "flow" to a developer and then "flows" to QA dept and so on ad infinitum.

The funny thing is that most developers subscribe to this metaphor.

I choose to think of programming skill as just that. A skill. Just because you have a skill at metalwork(say) you don't have to work on a boring job on a third world assembly line. Developers who build startups step beyond the "assembly line" mentality. They choose what to work on, how to work on it, what technology to use, what customers they target interact directly with their customers and so on. Others choose to work on opensource kernels or compilers. Others are dragged kicking and screaming into Project manager-dom.

Of course, you don't even have to make your money with your programming skills. You can be an investment banker (or astronaut or actor or musician) and do your brazing and welding on the weekends.

In my (totally personal) view, knowing how to program well is like being literate in a largely illiterate world. One day everyone (or almost everyone) will know how to write. But in the meantime you don't have to work as a scribe just because you know how to write. You could be a general or merchant or prince or cleric or warrior for hire or Dragon Slayer (umm ok note to self - less D & D) and your writing skills would give you a significant edge over your illiterate peers.

Just because you are a good programmer (you are, aren't you ? ;-)) you don't have to work for that 200,000 employee outsourcing company 12 hours a day on systems you don't care about with "industry standard",read "middle of the road" technology.

Unless you choose to.