Last week's announcement that HTTP PATCH has been adopted as an official verb via RFC 5789 has generated a lot of excitement (and questions). As a summary, the intention of each verb is:
- POST to create a new resource when the client cannot predict the identity on the origin server (think a new order)
- PUT to override the definition of a specified resource with what is passed in from the client
- PATCH to override a portion of a specified resource in a predictable and effectively transactional way (if the entire patch cannot be performed, the server should not do any part of it)
The goal is to convey the intent of the patch more clearly than is possible with the more generic POSTing of modifications. Specific patch diff formats will emerge for modifying plain text, HTML, XML, etc. Semantic Universe
This is huge. Finally we have more verb to refine REST APIs operation.
Charm Flickr (creative common license)
On face value, software development is the great equalizer because all you need is a computer, which is widespread and the Internet, which is accessible. But if you peek more closely in the industry, the challenges operating in a third world country is quite significant compared to first world - just as it applies to any other industries.
Nota bene that third world is off course encompass a large part of the world. I write this based on my experience in working in or dealing with operations in Egypt, Morocco, India, Azerbaijan and Indonesia. My first world experience are in Australia, Singapore, Czech Republic, Italy and USA.
English as Lingua Franca
English is more or less the Lingua Franca of programming. Most information about software are available first, if not only, in English. Although English comprehension is much easier to achieve, mastering the ability to write clearly in the language takes a lot of effort and time. This reduces the amount materials and critical thinking from third world programmers accessible to wider audiences because simply we do not write as much in English. I suspect that this also have a big impact on reduced open source contributions from the third world.
Immature local market
Local business software market in a third world is completely different that first world. We operate in an environment on which business systems are either new or do not exists. There are a much higher learning curve for the customers for their first system development compared to organizations that have relied and benefited from software for a while. Critically, things that software will optimize in the first world (thanks due to higher labor costs), might not make sense in the third world.
Different life rhythm
This especially applies to outsourcing projects. In Muslim countries like Egypt, the holy month of Ramadan completely change the rhythm of life. People fast during the day and more importantly, they spend more time with friends and families at night. All these factors do not bode well for productivities during the month. It is what it is and schedules should be adjusted to accommodate that. On the other hand, we keep on trucking during December.
Process adoption
Popular processes such as Agile or Lean are great ideas but again these ideas originated from first world countries with its own built in assumptions and conditions. Can it be applied successfully in the third world? I bet there are plenty of evidences that it can. Are there any other alternative processes that can be implemented instead that bring better results considering local conditions? Yes. We have been trying one in the past 18 months and the results have been encouraging (this is for another post).
Our major cities traffic are horrible and mostly polluted
We are more of a social animal that the stereotype "geek" being portrayed which means that we like to work in offices - together with our mates and colleagues. The problem is that most of the time our traffic are horrible and our public transports are non existent. You don't know traffic jam until you get stuck in one in Jakarta or Cairo. The bottom line is that all these just make work a bit more difficult than working in locations where the air is clean, public transports are available and commute are short.
We have to fight our education system
Our tertiary education system aren't that great. Yes we would have one or two example of excellence, but there are plenty more where our education system fails our students. This means that we have to invest more in training our incoming developers that we would have otherwise in first world.
Our operating environment is harsher
A third world country means there are big deficiencies in our government, private sectors and overall operating environment - in short we just have to deal with more bullshit and everything is a work in progress. All these saps more energy that could be otherwise spent on more productive things.
Different quality perception
One of the more frustrating aspect in operating in the third world is the difference perception of quality. What is acceptable in local market will not pass muster in international market and vice versa. There is also diverse cultural gap in terms of design and look and feel. What is considered as good design can varies and usually local designers are struggling to come up with designs that are acceptable to their foreign customers.
Anyway these are just several factors I would like to highlight in the reality of software development in the third world. When you see great software from the third world, try to appreciate on how much challenges that those teams and companies have to overcome to achieve that outside the technical and engineering work itself.
I work and live in Cairo, Egypt - so I get to see the Pyramids of Giza from my office window while you suckers have to pay thousands of dollars to pay see it for a couple of uncomfortable hours.
On the downside, I have to review resumes and interview people on a weekly basis for web development jobs.
A standard resume will list litanies of languages, frameworks and databases that a particular person has mastered - but rarely I see people list of protocols in there. Not surprisingly I have not interviewed any web development candidates that know their HTTP/1.1 cold. That is a damn shame.
I do not see universities teaching protocols as parts of their IT degrees either. Developer conferences sell the latest language and libraries. Professional IT traning firms drill down either Java or .Net framework to their participants. But nobody talks about protocols.
It probably because people think protocols are boring. Yes, protocols are boring and you cannot do some flashy demoware on them at conferences - but not mastering critical protocols in your daily work hinders your progress unecessarily. You will get by without knowing HTTP/1.1 as a web developer, but let's aim higher than getting by in a profession.
(image licensed by creative common)
When you get to know an underlying protocol, you will be able to figure out easily their weaknesses and strength and be able to make the appropriate decision on when to use this. Protocols also tend to last longer than just mere frameworks.The coolest thing about mastering protocols is that you get to know how things work. There are wonderful things to be discovered inside multitude of protocols that are available and being used everyday on the Internet.
I wish universities take protocols more seriously than they are now. They should be at least one course on mastering the most popular Internet and web based protocols and open formats.
Anyway, here is a list of protocols that a developer can learn much from.
-
HTTP/1.1 (the protocol of all protocols)
-
AMQP (a wonderful messaging protocol)
-
XMPP (a presence and messaging protocol and a whole lot more)
-
RelaxNG (not a protocol, but a joy to read - especially compared to XML Schema)
-
-
and there are a whole lot more.
I wish Steve Balmer can repeat his schtick of shouting Developers! Developers! Developers! to Protocols!Protocols!Protocols! It will do inumerable service to wider development community if more of us take mastering protocols seriously.