What do advertising and Pair programming have in common?

Q: What do advertising and programming have in common?

A: They're both creative work.  They both work better when there is > 1 brain working on the problem at a time.

If you'd asked me this question last week then I would probably have said "nothing much". 

But then, on Tuesday evening, during the Q&A session of our Scottish "Agile Day", Rory (our group-managing director here at VISION consulting - a former advertising executive and non-techie) put his hand up and said he was suprised that pair-programming wasn't a standard and common practice across the software development industry. 

He said that he's worked across many industries during his time in business and that every other creative endeavor would naturally put two heads together, because they were better than one.  He said that it was pretty much mandatory in advertising - otherwise, how would creative people create if they couldn't bounce ideas off of each other, and rein each other in when things start getting crazy?

I was suprised at his comparison.  Although we create stuff, I'd never thought of coding as a creative exercise in the same way that advertising and marketing is.  But from Rory's more objective perspective he could.

Q: What else we could learn from advertising and marketing ?

A: How to sell the "value" of what we do would be a good start.  It's only since I've started consulting that I've realised just how important this is. 

We techies are pretty crap at it.  In my own case, until recently, I've always thought that doing a good job was enough and that others should recognise it.  But then I also wondered why the folks who were less skilled than myself seemed to travel further in corporate life.  I've been learning slowly how to tell our "value story" without resorting to brown-nosing.

Comments

[Reinhard Haberfellner]

And there is another thing to learn from advertising: Nobody would launch a statement without decent spell and grammar check, but a lot of developers still think code review is limiting their freedom instead of appreciating the enhanced security, reliability and maintainability.

[John A Thomson]

Likewise in the world of engineering. At Motorola our greatest successes where when we worked in groups of two and more! Shame the company was ruined by bad management when technically we were streets ahead!

Another engineer and I were so successful as a dynamic duo that a loner techie once called us, "Nothin' but a pair of b.....s!" - just what we were aiming for on that particular day :-).