Interesting response, thought provoking;
The significant quote on "the idi...", we cannot write software fast enough to satisfy the demand(win the race !);
The Q is what can we do to catch up in terms of structuring ourselves(the id... among the developers) to benefit from the economic value of this racing gap ?
Best Regards
�
Shem Nnaggenda Nsubuga
Country Head of Information Technology
Standard Chartered Bank Uganda
Tanzania contact Tel: 255 22 2117352, AEN 255 2 6162; cell 255 741 771312
"Leading the Way in Asia ,� Africa and the Middle East"
| "Guido Sohne" <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED] 05/06/2004 09:16 PM
|
To: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> cc: <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Subject: RE: lug_: Re An analysis of OSS thinking and assumptions within the context of the African programmer] |
Hi James,
Always a pleasure to hear from you. Comments follow inline.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lunghabo
> James
> > In India, there are about 750,000
> > software developers against a population of 1 billion or so people.
> >
> > At this point, I should note that the difference is in my definition of
> > the word 'developer'. I define a developer as someone seasoned,
> > experienced and talented rather than someone who is learning, or on the
> > way to becoming what I call a 'world class' developer. A developer can
> > write a compiler, or a kernel, or a device driver. Writing a front end
> > to the database does not make you a developer, however writing the
> > database engine itself makes you a developer.
>
>
> You are entitled to your definition of a developer. However when you bring
> in the statistics of India having 750.000 developers, based on your
> definition, it is not true.
Very true. In the previous paragraph, my projection for the equivalent in
Africa was 'under 50,000'.
However, the definition of developer has a direct impact on the capabilities
of the group that we call developers. There is some point where a line has
to be drawn.
For example, is someone who writes Excel macros a developer? At some level,
this can be considered programming. The point where the line is drawn is
subjective, so everyone has their own definition.
I've chosen a line that, in attempting to reach it, will dramatically
improve the skills and capabilities of those who strive towards it. I'm
still trying to reach that line myself, but I'm comparing myself to those in
the more developed countries in a bid to reach parity.
> I had an indepth discussion with that programmer from India at Africa
> Source remember? He reliably stated that india is full of guys who have
> mastered "front end" programming. He actually even went ahead to say that
> their main preference as a destination for IT labour is because of the
> cheapness coz even for those skills of (front end) programming, they have
> the cheapest bargain around town.
This is not to say this is not valuable. I am taking a total look at the
technology capabilities going forward. Each part plays a role. High end
developers are essential to creating deep technological structures.
Programming can be considered to be a practice of tool making. Each module
or subroutine is a tool built for a specific purpose. Some use tools well,
but those who build tools better provide more efficiency.
Efficiency in the creation and usage of tools are inextricably linked. A
language is a tool to interact with the machine, a layer of abstraction that
dramatically increases developer efficiency. We could still use assembly
language or COBOL, but we don't - for very good reasons involving
efficiency, which translates in productivity, time to market, lower barriers
to entry etc.
Efficiency and productivity of the tools in use have a direct impact
economically on the avenues where money can be made. However, it is
important to realize that not all technological advantages can be directly
translated or valued into money. How do you value the gcc compiler? It is
available at zero cost, but it underpins almost all the free software
development efforts.
So getting a handle on the economic value makes little impact on the
technology value. There are two different value systems in play here. They
do not operate in a mutually exclusive way, but rather feed off each other.
> In Uganda, I know a number of free lance programmers who are not simply
> surviving but are living well off "front end" programming. Maybe it is
> high time you factored in the aspect of the ever increasing specialisation
> even in the s/w industry. Let those who work on the kernel do so and if
> the balance sheet allows you to only be competitive by working on the
> front end, then do so. Get the kernel from some one whose business model
> makes him competitive in that area.
Not a problem. However, in the medium to long term, this does not go
anywhere special. Think of what happened to all the dBase / Delphi / Cobol /
Clarion programmers. What is the value of the code now? Sure, the
applications run, but can the code be reused?
Those are all classic front end tools. However, the real value has been in
moving the technology forward. It moves in small steps and big leaps. The
small steps are the many applications created around the platform, and the
big leaps are cyclical changes in the platform itself.
Historically, the real money has come from being able to obsolete the small
stepping by taking a leap that changes the way things are being done. This
inevitable obsolescence puts an upper limit on the value that can be derived
from "front end" in the medium to long term.
One can argue that the timeframe for the expected lifecycle for "front end"
corresponds exactly to the short to medium term. This is the source of the
economic benefits that you refer to, that the solution is in itself useful
and valuable, even though it may be non-optimal. Moreover, optimal solutions
may even cost much more than the non-optimal solutions, so the "optimal
solution" is often in fact not economically optimal.
Specialization is good and inevitable but when you have specialization
without important components, you have dependency. I believe that dependency
is one of the biggest things holding Africa back.
On the horizon looms the next set of obstacles. One of these is the
inability to react to and create technologies in the early stages. Once a
technology is widely adopted, the benefits which come from being an early
adopter are lost.
Early adoption is extremely important. One could say that is a reason why
the United States is ahead in software technology in many areas. They
adopted early and reaped the rewards of being on top of the paradigm shift.
The Internet itself is an example par excellence of that strategy. India as
a software power is reaping early adoption that started in the late '70s.
One way of looking at underdevelopment is to view it as being late to the
table. This means that by getting there late, you develop less, since the
others are by comparison ahead. This is at the heart of underdevelopment.
Leading edge technical people are required if you are going to be able to
adopt technology early, while it is still in the formative stages. You also
get the chance to shape the technology.
If Africa drove its own technology, according to its own needs, with
solutions provided by its own people, things would be different. Every
computer would have a built in battery/UPS so that when the power goes out,
you don't get the machine dying, much like a laptop computer. I can attest
to the number of times the battery in this machine has saved me. And you
tend not to realize it until you need it, otherwise you just get used to
data loss, and it feels 'normal.'
> get my drift? Its more about the economics than the technology. Thats why
> some one once infamously stated that "Technology is too important to be
> left to the technologists"
Interesting comment. It's true. But technology is also a process of
interaction between the producer and the consumer. The feedback drives the
technology evolution process. Technology cannot be *adequately* handled
without the technologists, is my corollary to the statement above.
I've tried to think about the economics part of things and I'm sorry that I
have had to do that. I wish others would do this as well so I can also learn
from the ideas but it seems that this is a job that is being left to the
technologists, who are unwillingly, becoming armchair economists.
So where are the non technologists now? My hypothesis is that this is ahead
of their event horizon, because techies see further in technology and it
takes the non-techies a while to catch up and see the changes that are
coming.
Where would the pundits be without the technology and how would the subject
of discussion have been created without the technologists. Mostly, by the
time the techies have created the thing, they understand it and the issues
directly involved in it far better than any other people.
By the time the others understand, the techies are on something else, so the
current output still seems garbled, even though the earlier output now
starts to make sense. OSS is a perfect example. Techies started this in the
early 80's but it is only now that the rest are getting on board. This is a
20 year gap in understanding, or more accurately, a propagation delay.
People are now eagerly promoting what was being promoted almost ten years
ago. This is my personal case. I started investigating and advocating OSS
somewhere in 1996 or so. No one would listen then (many still don't, which
is why a main goal for FOSSFA is advocacy!). It's gratifying to have people
do so now. The problems and weaknesses of OSS have not been well thought
out. It will surely come to that one day, by which time, I hope to have
found newer things to do.
Many problems in technology use actually come from poor understanding of the
issues by those who did not create it. That's why people need manuals. When
the result is thrown to the consumers, or the end users in the case of
software, all bets are off.
Someone once famously commented, "There is a race between software engineers
and idiots. The software engineers constantly strive to produce more
idiot-proof software, and the universe strives to produce more idiots. So
far, the universe is winning."
Having said that, software engineers have more than their own share of
idiots. Who is really to blame is probably all of us ...
Thanks for the feedback. Much appreciated.
-- G.
---------------------------------------------
This service is hosted on the Infocom network
http://www.infocom.co.ug
---------------------------------------------------------
This email is confidential. If you are not the addressee tell the sender immediately
and destroy this email without using, sending or storing it. Emails are not secure and
may suffer errors, viruses, delay, interception and amendment. Standard Chartered PLC
and subsidiaries ("SCGroup") do not accept liability for damage caused by this email
and may monitor email traffic. Unless expressly stated, any opinions are the sender's
and are not approved by SCGroup and this email is not an offer, solicitation,
recommendation or agreement of any kind.
Standard Chartered Bank ("SCB") is a member of SCGroup incorporated in England with
limited liability. SCB's principal office is 1 Aldermanbury Square, London, EC2V 7SB,
UK. SCB is authorised and regulated by the Financial Services Authority ("FSA") and in
FSA's register under no. 114276. SCB's VAT no. is GB244106593. FSA is the lead
regulator for the SCGroup. For regulators in other countries contact the local
compliance officer.
---------------------------------------------------------
