Outsourcing without code monkeys!

If there is one thing that we are really scared of at Kaz, it is "code monkeys".

Before I elaborate, let me define the exact meaning of the words "code monkey" in the context of  software development outsourcing - since it's not exactly well established expression outside the techie world.

Here is what I get from google if I do a define:"code monkey", courtesy of http://http://en.wikipedia.org/wiki/Code_monkey

"A Code monkey is a computer programmer or other person who writes computer code for a living."

Ahem, that doesn't help. Doesn't "...who writes computer code for a living" cover pretty much the entire professional software development community?

Much better are the definitions in this page:

http://www.urbandictionary.com/define.php?term=code%20monkey

And to be precise, in the context of outsourcing or offshored software development the definition that we are worried about is:

Code monkey:

"A programmer who isn't actually involved in any aspect of conceptual or design work, but simply writes code to specifications given."




Thanks to Phil Hawksworth for the pic.



But I love the other endearing definitions too but they are more about us in general, a downside (or upside - depending on how you look at things) of the profession we chose (or the only profession in which we could fit ourselves in). One very worrying definition on a personal level is the: "One who copies all code from other sources and prays that their code compiles." - how did these guys know about me????

But let me get back to the subject I promised to write about -

How do we manage to do outsourced software development without code monkeys?

That is: without creativity of initial design, without constant criticism of the architecture that they are implementing and eventually without care. Writing code because that's their job rather than writing code because it's their passion.

You might be thinking: "hey that’s a no brainer, you just get involved in conceptualization or architecture or do what you need to do make sure that you are not just blindly following specs whether you like it or not." But see the real problem is in the word "outsourced" in that question. Outsourced software dev would also bring in some if not all of the following concepts with it:

  

Someone outside your team

· conceptualizes the software.

· designs the architecture.

· does the UX

· writes the spec.

· defines the technology stack.

· etc.

Not so easy now, right? So how do we meet this challenge?

First and foremost, we are pragmatic.

We ARE an outsourcing shop - and by its very definition we would be helping someone outside our team build their software. So it is inherent in the model that someone else will be involved in any or all of the processes that make software possible. The question we ask ourselves is that how can we fit our desire for not being code monkeys in to this scheme and how can our clients benefit from our creativity. Here are some strategies we use:

0. Be open to the client from the very first day.

This is the obvious one - but you'd be surprised by how many companies fail on this. There is a feeling, and I think the biz side is to be blamed for this (sorry, all techies are saints and all things evil is for biz, of course!). Seriously, I think there is a feeling that an outsourcing company needs to give a feeling of extreme cooperation and compliance in every request made by the client. This is a major disservice for the clients. Technology is a field where there is no absolute right or wrong and it is the duty of the technology partner to be brutally frank about everything.

If the design is "**it" in the view of the software developers then it will always stay "**it" for them - it needs to be declared as such and argued out to the point where both sides either compromises or at least knows what are the basis of the decisions taken. 

The way to start this is right at the beginning. This would set the tone of the relationship and open up the culture of expressing thoughts freely. Yes, sometimes, on rare occasions this would be so against the culture or working mode of the client that it will create discords in the project. And I say that in such cases it is good to have that discord right at the start. If the disparity is such that the client leaves - then that is good - since if the fit is not right, an outsourcing project will ALWAYS fail. 

1. Setup a role both on client and our side which is just to air out our thoughts of discontent about design, feature, etc.

One of the unusual roles that we setup in our project team is that of the "Chief Complaints Officer - CCO". There is a CCO on both sides - client's and ours. And the duty of the CCO is to, you guessed it, listen to complaints and communicate those to his counterpart. This works both ways really - the CCO on the client side would regularly be telling us how their tech or management team thinks that our ideas just won't work etc.  

The CCO is typically the PM on both sides - but having this official unofficial role makes it simple to air out feelings through a proper channel. 

2. Initiation of any project goes through a period of critical analysis.

When we move to a new outsourcing project and a team has been formed for that one of the first thing we do as a team is to do a series of analysis sessions. The subject of the analysis could be whatever is the starting set of objects that we have - be it a feature list, a spec, design diagrams or an existing codebase.

These sessions serve two purposes - a)they give us a better understanding of the outsourced project but more importantly b) they make it possible to make the project "ours". The decisions of the project become "our" decisions rather than "theirs" because we fight it out amongst ourselves (and where needed with the client) and we accept the final set.

This, making things "ours", is critically important to avert the code monkey behavior. When it is yours you give it the love that it deserves and a lot of the times love in dev world is criticism and refactoring :)

3. Begining of any cycle arrange for an internal fight for and against the features, technology and the designs to be used in that cycle.

Same as 2, but on a smaller scale this time.

4. Create and maintain a culture where there is no fear to say what's on your mind.

This is cross cutting across everything we do at Kaz. A philosophical stance, for us. Software just cannot be made where you are not free to say what you feel about that software or anything related to it (well sometimes just about anything really).

Check out our culture page or our FB page for a glimpse of what we are like.

5. Hire people who are strong in airing out their thoughts.

OK. If you want to forget everything I said but want just one idea, this is the one. No plans work without the people implementing the plan. So at the end of the day every strategy is just a set of words unless you have the right people.

We hire the best developers. But one of our unusual interview technique is to see how a person manages arguments and how passionate they are about their views. It's easy to start an argument in the software development profession (with the right kind of people that is) - a simple "this would have taken a min to write in Python. I have no idea why people use C#" or something like this usually does the trick. But in general there are much subtler tacks than that.

Not an easy combination though - finding the right mix of talent and ability to communcate dissent. But it is one of those core challenges that you just have to face in this business.

Let me finish today by escaping this "teacher" tone of this article with a joke I came across when googling for code monkey:

“Q: What do you call a monkey who works in a call centre?”

“A: A who-rang-utang!”

:)