Re: Open Source Funding: Developing Countries Better?

[Daruma]

Greetings!

The "Bang for the Buck" concept is one that is affecting my current employment. The company I work for is seeking "offshore" developers based upon the rate they have to pay for the work done. While, from a cost basis, this seems like good business sense, it has not quite worked out that way.

Many of our developers have had to move to a more advisory role. Their duties now include writing specifications, both functional and technical, which are very detailed. The detail needed to "coach" the development of the required code is not much less than the effort actually required to do the coding work itself.

Many of the folks tasked with writing these specifications and guiding the new developers have indicated that they could have completely finished the coding work with very little extra effort.

This does not mean, however, that the relatively inexpensive coding labor force cannot eventually "learn the ropes" and require less guidance in the future. It does indicate, at least to me, that the cost savings are not quite as drastic as the PHB might have hoped.

In placing Open Source Project funding in "developing" countries, what are we hoping to gain? Is it purely financial? If so, this should be thought about very carefully. If it is to encourage the learning and development of skills in those countries, I feel it a better cause.

-Daruma

[woolfy]

Many of our developers have had to move to a more advisory role. Their duties now include writing specifications, both functional and technical, which are very detailed. The detail needed to "coach" the development of the required code is not much less than the effort actually required to do the coding work itself.

I have run a company myself, started with two (myself and my partner) and 5 years later grown to over 40 people. I learned management and especially projectmanagement the hard way: by doing it, and trying to read something about it at the same time, and having the problem of recognizing good texts from hype and air.

Management is an issue here. The development of Perl is managed by a small group of people. Most of whom should just be developing, programming, testing. Instead of going to conferences or managing programmers that have way less experience and skills than they have.

Project management is another issue. Again, many project managers lose a lot of time on management issues, that they could have spent better just programming themselves.

Many projects and good products have gone down the drain because of the multi monkey approach. That is: put more monkeys on a project and the project will be finished sooner with a better result. But that approach seldom works. The opposite is more true. The best programmer in a team is appointed to be project manager, which is not his (her) best virtue. This programmer does not have the time to program, but tries to tell the other programmers how to do their work. Too often I have seen a team of programmers expand, staying at the same productivity rate and the project manager go nuts. While this manager as a programmer could have half of the work himself (herself) would he (she) have been left alone with just a bit of management from a real manager.