The Software Purist |

TAG | Zone

Dec/09

4

Software Outsourcing, Part II

If you have not read part I of this series, please check it out first:  My Experiences With Software Outsourcing. My first entry in the series discusses some of my experiences with outsourcing. In this second installment, I discuss these issues a bit deeper and provide my overall thoughts on outsourcing.  I’ve already gotten some great comments on the first article, which I appreciate.  One thing I should clarify is I’m not against outsourcing, just against certain approaches and motivations by companies who decide to use outsourcing.  In this article, I present scenarios where I think it may work.

Overhead

As I mentioned in the previous edition, time difference can be a huge factor.  Teams that are intertwined often need to work closely and need more immediate feedback.  The only way to reduce this coupling is… well, to reduce the coupling.  Therefore, I am of the personal opinion, that in outsourcing, much like software, there should be a large desire for low coupling, high cohesion.  You have to trust your outsourced developers to do the work with the right instruction.  If you don’t have this sort of faith, then outsourcing is not for you, because the overhead can be high enough to defeat all discounts, and potentially, even be more costly.  Having dealt directly with this, I know from experience.  Ultimately, the goal is to desire economies of scale and avoid diseconomies of scale.

Low Coupling

High coupling occurs when any one person is free to contact any other person in the company.  Not only are they free to, but it is encouraged.  This can happen in one office.  The problem is if a single person takes direction from multiple sources, it’s more time cumulatively time consuming.  This can be deceiving, because to the person who made the request, they often got feedback quicker than if they had to go through channels.  However, for the person who served his 30th request of the day, it is well known that this is not efficient.  If this person who has been communicated to, by so many people, is a developer, all of this intercommunication prevents entry into “The Zone”.  This is one area where all of these channels of intercommunication can be the most costly.

The reason why this behavior is so prevalent is very simple.  It works extremely well when a company is small.  In a 10 person company, every person knows every other person and likely communicates daily.  But there’s a reason why this is so efficient: The company is small enough that there is likely no more than two managers, and everyone is strictly focused on work and completing their own tasks.  Then, each person merely talks to the person who he or she most needs to communicate with to complete his or her task.  The problem is that, as you likely realize, it does not scale well at all.  Putting project managers in place is a step to reduce that, since the project managers can act as the point of contact.  However, it doesn’t go far enough, unless the offshore project manager is given more authority, and the onsite project manager is more used for communication and just communicating ideas back and forth.  When it goes further that this, I believe it’s demotivating for the foreign employee to be working through multiple layers of management and messages being relayed.  And of course, it’s costly, resulting in a lot of rework, due to miscommunication.

My ultimate recommendation here is that each office should work on disjoint projects, with potentially different sets of standards and rules.  I think it’s tempting at first, to couple things tighter, because from a company perspective, it makes sense to not duplicate work.  As a purist, I feel that duplicate work is generally not cost-effective.  However, in this case, I think it’s sometimes acceptable, mostly because the alternative may be worse.  So, I generally feel that in order for the scheme to work, it has to be treated as almost two different companies.  The US location should act and be treated like a customer.  The foreign location should act and be treated like the supplier of the software.  In this scheme, I think it can be valuable, because you forego most of the overhead of the interoffice communication, except from the perspective of a client, who is concerned with functionality and not dictacting architecture.

Motivations

The last thing I wanted to talk about in this installment is the motivations behind outsourcing.  The obvious motivation is saving money.  There’s no doubt about this, and it’s justified.  However, I see outsourcing as an opportunity.  You are getting developers for a fraction of what they would cost in the US.  Some companies take this a step further and even look for a deal in those countries.  I have to say, I think this is going overboard.  If you’re already getting developers at a fraction of the cost, why would you then proceed to also get inexperienced developers to save a few extra thousand per person per year?  If I was me, I’d pay highly there to get the most talented. It’s often cost prohibitive to get the most talented developers in the US, but abroad, it isn’t. I also feel that by getting the most talented developers, you get people you can trust to do the job, which also flows well with the concept of keeping overhead minimal.

Conclusion

Studies have shown that the cost benefits for outsourcing are often minimal, especially for companies who are seeking a deal. In pure cost analysis, because of the inherent overheads, it can provide little cost benefit, or in some cases, even be more costly.  I discuss scenarios where outsourcing might work, but it needs to be done with care.  If you’re a discount shopper, you may be fooling yourself.  If you use outsourcing to simply increase the pool of talented individuals who you may employ, the strategy has potential to be effective.

· · ·

Nov/09

28

“The Zone”

One of the mysteries of software development, as well as many other professions is the concept of “The Zone”.  This is also known as “The Flow”. Wikipedia defines it as this, “Flow is the mental state of operation in which the person is fully immersed in what he or she is doing by a feeling of energized focus, full involvement, and success in the process of the activity.” You can witness this in a sport such as basketball. I recall quotes from Michael Jordan, in the 90s, about a game he had in the NBA finals, and how he was in the zone, as he singlehandedly led his team to victory.

The fact is that when you’re in the zone, you’re performing way above your normal state, things come naturally, thought is mostly unconscious, and you have extreme focus, which ultimately lets you process things far more quickly and effectively. Ultimately, developers get in the zone too. I know when I’m in the zone, I’ve done multiple days work in what would otherwise take a few hours. This usually happens for a combination of reasons: being well rested, interest in what I’m doing, determination, and a concept of a goal that I want or need to achieve.

I know other developers I’ve worked with often talk about a similar process. A mentor of mine from years back once said that he often starts a project slowly. Then, when he’s working, suddenly things just “click” and he quickly makes up for lost time, and that’s why his performance was good. I think this happens to a lot of us. I believe that the moment when things “click” and suddenly in the course of a few days you get a massive amount of work done is “The Zone”. In software development, the zone doesn’t happen all the time, and it needs to be realized that it’s important when it does.

Breaking the Zone

One of the challenges is the zone is working in an office workplace, where there are potentially a lot of distractions to remove you from the zone.  Mostly, I find these to be other employees.  Ironically, the lower you are in the chain, the more zone opportunities you will have, because generally you have less points of contact.  Each time, as a developer, I’m interrupted, it can be as short as 10 minutes and as long as an hour before I re-enter “The Zone”.  This kind of productivity loss should be considered unacceptable for most companies.  If you’re a company saving a few dollars by keeping the employees crunched together, shame on you.  It provides more stress for your developers, who are often, not a social bunch to start with.

Keeping the Zone

Obviously, as Joel Spolsky suggests, giving each person their own office is a big help, because it reduces the temptation to distract others.  This is a huge benefit, but it’s probably not possible for every company.  In general, I think high wall cubicles are also fine.  Noise levels should be kept in check by management and policy: Keep outloud music to a minimum, personal conversations should be taken elsewhere, and impromptu meetings should be a rarity and should occur in conference rooms.  This policy should be enforced and if someone is violating it, they should be asked to be more considerate.  Having inconsiderate neighbors is never a good experience.

Another thing that helps is investing a good set of headphones.  For some people, it’s best to get a studio-style headset or gamer headset, which will block out almost all noise.  If you want to be aware so you can hear nearby voices, but ignore most sounds, you can use a cheaper headset.  Again, though, note that this can be an unnecessary distraction for you, but can definitely be a tool for the paranoid.

Conclusion

“The Zone” is an psychological state every developer loves getting into.  The work flows faster, better, and with higher quality and focus.  It is sometimes difficult to stay in the zone when working due to outside distractions, but with some careful techniques, companies and individuals can make it easier to stay in “The Zone”.


· · · · ·

Theme Design by devolux.nh2.me