The Dubai Meltdown and the Importance of Creative Conflict

The Dubai meltdown is another disaster caused by groupthink.  No one in the emirate was willing to question the soundness of its development plan until it all came crashing down.  

One of the most difficult things in Asian business is encouraging a culture of frankness and the willingness to challenge opinions of one's co-workers, even one's superiors. In most Asian cultures, conflict is something to be avoided at all cost. You will almost never hear an outright argument in an Asian boardroom.

Yet conflict is essential in any healthy organization. An organizational structure naturally puts people in conflict with one another - Sales is in conflict with Operations since more sales means more of a burden for Operations, at the same time Sales may be selling something that Operations cannot effectively deliver. Finance is in conflict with other departments as it seeks to control costs, while at the same time it may be hampering the ability of the departments to operate effectively.  And there should be a natural conflict between the CEO and his department heads since it's his role to critique the others' work, while the department heads should question the soundness of the CEO's overall plans.  

If people care about their work, they will end up coming into conflict with one another. Many of these conflicts can be resolved amicably, but not all of them. Either an outright conflict can occur, or people just bury their disagreements in silence. In most Asian cultures, an outright conflict is usually taken as a personal attack, and permanently harms working relationships, which is why they're usually avoided. Burying disagreements in silence is the more common choice, though very little gets resolved in this route.

The worst case is when people stop caring about their work! Conflict stops, everyone is enjoying cordial relationships, but a disaster is lurking just around the corner.

What you want to encourage in your company is a culture of "Creative Conflict". Everyone in the company should come to expect that conflict, even outright arguments, are a natural part of their work environment. In an environment where everyone cares about their work, each one should be willing to argue their opinion on what they think is best for the company. Each one in turn should be willing to listen to the logic of another's argument, argue back if necessary, with the intention not to win but to find the best solution to the issue - something that's not easy to do when tempers are already involved.

At the end of the day, people should have the attitude of considering arguments as all part of a day's work.  Arguments should never be taken personally.  Two people who just had a yelling match during the afternoon should be able to have a drink together after work.  

It's a huge cultural leap for most Asian companies to embrace conflict as a part of their culture.  The amount of effort to change people's mindset about conflict is huge since it's ingrained in our upbringing.  However, if you seek an environment where people care about their work and where problems are resolved quickly instead of being swept under a rug (where they continue to grow), a culture of creative conflict is key. 

No to email first thing in the morning?

I'm thinking of starting my day by NOT reading emails.  Reading emails just shatters my brain into dozens of pieces.  Just holding all those things in my head keeps me from doing any thinking that involves some level of analysis, such as long-term planning or thinking of solutions to tricky company issues.  

I do my best thinking early in the morning and starting my day by going through my inbox means I waste this optimal thinking-time on knocking down whatever tasks that seem urgent at the time.  This was a survival mechanism I acquired when we were a less-than-twenty-person company, where every hour I wasted in not turning around work into revenue meant life-or-death for the company.  But now that we're at almost a hundred, I now have the unfamiliar luxury of being able to delay a decision by hours or days, and it won't kill the company.  (Transitioning from startup-survival mode to mid-size-strategic-thinking mode is a regular theme for me.)

So wish me luck on trying to avoid my inbox first thing in the morning!  I hope I succeed. :-)

Sony VAIO freezing when connecting/disconnecting from external monitor (fixed)

For the past couple of weeks, my Sony VAIO (VGN-SR35G) would freeze everytime I would connect or disconnect an external monitor or projector.  I was originally on Linux Mint Gloria, then I tried Ubuntu Jaunty, and even tried upgrading to Karmic Alpha 4.  Same thing would happen.

I finally found the fix here.  Just add the line to the "kernel" entry in /boot/grub/menu.lst.   See mine below as an example, the part I added was in bold:

## ## End Default Options ##
title           Linux Mint 7 Gloria, kernel 2.6.28-11-generic
root            (hd0,0)
kernel          /boot/vmlinuz-2.6.28-11-generic root=/dev/sda1 ro quiet splash acpi_osi="!Windows 2006"
initrd          /boot/initrd.img-2.6.28-11-generic
quiet

Thanks to O&B Sysads Onin and Armand for your help!

Got OpenERP Server running on Mint Gloria (Ubuntu Jaunty)

Finally successfully ran OpenERP Server.  Not sure if everything else works yet, but it's running.

I'm on Linux Mint Gloria, which is essentially Ubuntu Jaunty.  Every time I try to run "openerp-server", I get this error message:

    ERROR: Import xpath module 
    ERROR: Try to install the old python-xml package 

Here's my fix:

1. Downloaded and installed the .deb of version 5.0.1 of openerp-server (the Gloria/Jaunty package is v.5.0.0) from packages.debian.org.  Installed the 5.0.1 client as well.
2. Created this symbolic link:  sudo ln -s /usr/lib/python2.6/dist-packages/oldxml/_xmlplus/utils/boolean.so /usr/lib/python2.6/dist-packages/_xmlplus/utils/boolean.so

And it ran!  Still haven't tried anything else but run the server.  Don't know if anything else works.

Thanks to this thread for helping figure things out.

PSIA Technology Council Blog Aggregator now up!

The PSIA Technology Council blog aggregator is now up!  So far we only have four feeds but we'll get more soon.  Right now, we have the following:

Deng Ching, Project Management Committee Chair for the Apache Archive Project

Mike Mallete, Philippine Groovy/Grails User Group founder and president, and author of the Grails SoundManager plugin

Albert de la Cruz, Platform Strategy Manager of Microsoft Philippines

Dean Berris, Boost C++ contributor and high-performance, parallel computing specialist

Orange & Bronze is now an Official SpringSource Partner

Orange & Bronze became an official SpringSource partner last month.  Initially, we were working on separate official partnerships with G2One, maintainers of the Grails framework, and SpringSource.  This was as far back as June of last year, where we had some initial conference calls with Jeff Brown, Grails committer and then G2One Director of North American Operations.  I also met with Mitch Ferguson, SpringSource VP of Business Development, in August of last year, at the SpringSource headquarters in San Mateo.  Little did we know that SpringSource would acquire G2One!

We've been working with the Spring Framework for such a long time now.  Many of our architects have been working with Spring way before O&B even started.  In fact, even before the Spring Framework came out, I was organizing PinoyJUG sessions based on Rod Johnson's book, "J2EE Development Without EJB".  I can safely say that, as a company, we are far-and-away the top experts in the Spring Framework in the Philippines.  Almost all of our projects are based on Spring, and Spring-based technologies such as AppFuse.  We also run a healthy business in conducting Spring Framework training courses, with major software development firms as clients.

Early on as well, we were evaluating dynamic languages and frameworks based on them.  We've looked at Ruby on Rails, Scala, and have even used Python and Django in production work.  By far however, we've found the most practical framework for enterprise applications to be Groovy and Grails, mainly because it was based on mature technologies like Spring and Hibernate.  We have begun using Grails as a replacement for AppFuse when building new enterprise applications.  When the Philippine Groovy Users Group (PGUG) formed, we immediately offered them sponsorship, including freedom to use our office for its meetings.

All-in-all, we've been finding SpringSource technologies the most practical choice for our enterprise software development work.  We have been early adopters of these technologies, and as a company, have established ourselves as the foremost experts in these technologies in the Philippines.  It just made sense to establish official ties with SpringSource.  We have very exciting plans in the coming months revolving around Spring and Grails, and looking forward to closer collaboration with SpringSource.

Cost-Savings in Offshore Software Development Outsourcing

How much do you really save when outsourcing your software development offshore? What are the hidden costs of offshoring?

Compensation & Benefits Comparison

First of all, let's start with just a compensation and benefits comparison. When doing your calculation for an onshore hire, don't forget to include the cost of such benefits as social security, healthcare, pension, time off and even bonuses. According to Salary.com (as of this writing), the total average US compensation and benefits package for a Java Developer comes to $112,435 a year.

An offshore Java Developer in the Philippines, India or China, on the hand, usually costs somewhere around $20/hr, or around $40,000/yr. This is all-in since you don't cover any benefits. Your savings on comp & ben alone is $72,435/yr per developer, or 64%.

Infrastructure & Overhead Considerations

After comp & ben, consider your onshore infrastructure and overhead costs. This of course varies widely from company to company, but do consider rent, renovations, new furniture, new computers, administrative overhead, exposure to various legal liabilities, training, etc. And if you're ramping up quickly, consider that a lot of these will be upfront capital expenses that will take a toll on your cashflow. With offshore outsourcing, these all become the costs of the vendor.

"Hidden Costs" of Offshoring

On the other hand are the often-talked-about "hidden costs" of a distributed, outsourced team.  The cost of these "hidden costs" varies widely - sometimes the cost is not significant, and sometimes the cost is a deal-breaker. What factors affect the cost?  The biggest factor is your choice of outsourcing partner.  You'd want a partner that is concerned about the increased cost of management on the client side, and has therefore invested in processes, tools, culture and technical ability to lower that cost.  

Process.  Look for an outsourcing partner who's an expert in your preferred development process.  If you're an RUP shop, you should pick a partner who's already mature in their RUP practice.  If you're a Scrum shop, then pick a partner who's mature in Scrum.  If you're a CMMI shop... you get the picture.  It doesn't make sense to try to teach your partner how to do your process - that's way too much of an investment.  Your partner should know your chosen process better than you do.  

Culture.  It's also important that you look into your potential partner's corporate culture.  You should look for a company where the desire to serve the customer and solve the customer's problems is present at the individual level. Remember that these people will likely be working while you're sleeping and sleeping while you're working.  They need to be motivated on the individual level to solve problems as they happen and not be complacent to wait for feedback or help from your side before they move.  

Individuals should be assertive enough to proactively communicate and collaborate with your side.  The time difference and distance make it essential for both parties to actively seek collaboration from the other for issues to be resolved quickly, it just doesn't work if those on the vendor side expect for communication and initiative to come mainly from your end.  This is an important point, since most Asian cultures favor power distance.  You should look for a company that deliberately fosters a culture of assertiveness, since this is not natural in most Asian countries.  

Technical Ability. Technical ability also contributes to the cost of offshoring.  Your senior developers are not there to oversee the quality of the developers' work, and reviewing work the next day and trying to correct errors via email just doesn't work.  Your vendor must already be experts in the bulk of the technology you use.  For the parts that they don't know, they should be smart enough to figure things out on their own.  You shouldn't have to conduct any training for them unless it's on the domain or some proprietary technologies that are not widely known.

The vendor should have a very strong CTO, or better yet, a strong team of seasoned architects.  The vendor should have its own group of mentors and pinch-hitters who can oversee quality, mentor the more junior developers, and conduct their own internal training programs.

Conclusion

Don't let offshore outsourcing scare you.  Offshore outsourcing has been a strategic factor in the success of many companies, from small startups to large enterprises.  Horror stories do abound, but those are due mainly to the wrong choice of partner.  Find a partner that knows what they're doing and matches your style.  Offshore outsourcing has its well-known issues, but a good outsourcing partner is one who is an expert in these issues, and has invested in the expertise, process, infrastructure and culture to mitigate them.