Ravi Mohan's Blog

Saturday, March 15, 2008

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.

7 comments:

Siddhi said...

I'm doing a project like this (working alone). It doesn't imply assembly line or replaceable or any of those things. That's your bias kicking in :)

Of course, managers who don't get it might choose to interpret it like that (very likely I'd say), but if someone wants to muck up their project, thats fine by me :P

Ravi said...

"working alone" *by definition* falls out of the "assembly line" metaphor! Whoever heard of a one man assembly line?

I wouldn't expect *any* one man project to feel like or refelct an assembly line!

You might want to read the blog post again ;-)

Anonymous said...

@Siddhi,


From your blog, it seems you are running a startup using Python/Django, essentially running a one man show. That's a great position to be in but frankly it has nothing to do with (and is probably the direct opposite of ) the kind of projects Ravi was talking about in this post. He does explicitly allude to the software services industry.

@Ravi
Great post! I needed some motivation to quit my job in the (not outsourced thankfully) software services sector. This is it! I am gone!

Anonymous said...

"Unless you choose to."

Excellent - agreed. Its all down to the ethos of the company.

Anonymous said...

I guess its time some one started a YCombinator in India ...

Siddhi said...

Exactly my point. You have the same workflow to talk to the customer, develop, test, deploy etc etc, whether one person or many. In a one person shop its the same person doing everything thats all, but the workflow is the same.

There are one person shops that do all the coding, then all the testing, and there are one person shops that do one feature to completion then start the next one. So the number of people and the methods are not related in any way.

Ravi said...

Note to commenters:

"Assembly Line" (in the blog post) is a **metaphor** (in the Lakoff-ian sense) not a description of reality.

please parse that before commenting! saves your time and mine!

Thanks in advance,
Ravi