Develop Research Culture in the Arab Middle East

It was only 2002 when I first knew ACM even existed. I was preparing my master’s thesis in computer engineering in Iraq. I was so amazed I thought of ACM members as movie stars. Due to many circumstances, I did not have the honor of joining as a member until 2010. Having received my bachelor’s, master’s, and Ph.D. in the Middle East, I have always seen a gap, a large one, between the way research is conducted there on one side and in Europe and the U.S. on the other. This feeling has been enforced whenever I get a rejection letter for a paper sent to a big computer science conference or journal. Sometimes, unfortunately, reviewers have mocked and even ridiculed instead of provided a constructive review. This happened in the early stages of my own research, and, as I learned later, to many of my colleagues as well. In most cases, when I look at Arab scientists who have published in reputable conferences and journals, I see author names of those who have either studied abroad or are working abroad, many very successful with outstanding research records. What does this say?

The Arab Middle East needs a cultural revolution in terms of research, especially in computer science. The research mentality here is quite different from other areas of the world. This is not to say it is not scientifically valid, just that research here is conducted in a different way that needs to be formalized to conform to international standards. Many researchers in the Arab world have amazing potential. Unfortunately, that potential is not being unleashed until they go abroad.

I sincerely hope ACM takes the initiative in helping spread a valid and concrete academic research culture in the Arab world. We all aim for the same thing—improving the quality of life for ourselves and for the coming generations. The lack of tools and research culture should not prevent Arab computer scientists from contributing to the development of all humanity.

Mohammed M. Alani, Muscat, Oman

Back to Top

Still Looking for a Development Blueprint

I agree with much of Phillip G. Armour’s Viewpoint "Estimation Is Not Evil" (Jan. 2014), but there were several important aspects of real-world software development environments he did not mention and which I have encountered in my own 30 years in software development. For example, I agree with his complimentary characterization of the Waterfall method as not being overly rigid or unable to handle changing requirements and encounters with unknowns. I also suspect a good part of the criticism of the Waterfall method comes from people who never actually worked in software development in the method’s heyday. I also agree with Armour’s praise for the Agile method’s focus on generating the most value in a constrained period of time. The Agile method is great for keeping customers involved in a project, though many (in my experience) neither want nor have the time to be too closely involved; they just want the software finished and to provide the functionality they had in mind.

I also agree with Armour’s description of the calculated risk-covering reserve as being part of the overall commitment. In managing software development (mostly in small companies producing custom applications for outside customers), I have found the final price and schedule are often agreed to in the sales process prior to any real-world estimation by the developers. Alternatively, even when developers do have input, I have heard upper management say, "We acknowledge your concerns but will not budget for them," even though it is a rare software project that has nothing go wrong or does not take longer than expected. I have also heard, "We acknowledge your concerns but cannot sell the project at a price including budgeting for risks."

In the end, the software team takes the risk and is targeted if the non-risk-reserve-bearing commitment is not made. A software developer might think a workable solution would be to get the customer to buy into the risk-reserve idea, assuming, if the risk does not materialize, the customer gets the product at the lower price. In practice, however, this does not seem to occur very often. Customers know once they agree to a higher potential price, they will almost certainly pay that price. This scenario could occur for any number of reasons, but one I did not always appreciate was that once a customer agrees to the "potentially" higher amount, vendor management inevitably solidifies its own budgets based on achieving the full amount, sometimes exerting internal pressure on the development team to do so.

I understand Armour was primarily addressing the Agile method’s relationship with estimation, but I was hoping he would have offered some advice that would give software developers a workable blueprint for successful software development. Even with Agile and estimations we do not seem to be there yet.

Richard H. Veith, Port Murray, NJ

Back to Top

Author’s Response

Veith raises an interesting point about negotiating the cost of risk with customers. In a few instances, and only where the customer-vendor relationship is on a truly honest basis, I have seen the customer engage in a useful dialogue about who should bear the risk and how much risk is appropriate. Uncertainty and risk are intrinsic to software development, and a mature process would acknowledge and optimize it. We are getting better but are not there yet.

Phillip G. Armour, Deer Park, IL

Back to Top