The (Unofficial) ITWorx Technical Architecture Blog

Archive for the ‘Rant’ Category

Blackberry blood on the Tarmac

Posted by archworx on September 22, 2008

Last week I was taking my son to the doctor, and as I was lifting his car seat in place, I rested my phone in the crevice between the hood and the windshield. We then got in the car and the started driving away.

I completely forgot about the blackberry.

A few minutes later I notice the phone in its holster was slowly edging up the windshield – in what seemed like an eternity – and within a couple of seconds the berry had flown off the car. The trouble is I was on the ring road!

I parked my car and I spent the next TEN minutes pacing back and forth the highway’s four different lanes trying to find parts of it. I knew it would certainly not work, but I just wanted to see if I could recover the data card with some baby pictures of my son and my sim card.

I found the phone itself, then the holster, then I spotted the back cover doing umpteen somersaults in lane 3, its black cover faintly visible in the night, its reflections caught my attention as it was flying in mid air.

Try as I might, I couldn’t find the battery. My wife spotted it near where we were parked and then we re-assembled it.

Ten minutes later (it takes ages to boot) – we were thoroughly shocked when the thing actually worked! Parts of the phone had been hit by cars, trampled on, and blown away by the speed of the cars passing by.

It had a few scratches here and there, the back cover wouldn’t fit snugly any more and the holster’s magnet broke, so now it speed dials a random number sometimes as I place the phone inside it.

Now that’s resilient engineering.

Well done RIM.


Posted in mkaram, Rant | 6 Comments »

Interview Completeness

Posted by archworx on August 18, 2008

I often find myself in a situation where I am interviewing someone, and I am starting to be impressed, when all of a sudden, I decide to ask one more question, jut for the heck of it – and suddenly I realize that I have uncovered a major gap in this person’s profile. Which brings me to the question – what do you think makes the complete interview? Both in terms of categories and what those categories may include in terms of questions. Off the top of my head I can think of the following main categories:

* Technical Competence

* Depth of Experience

* Gauging Passion

* Compatibility Company Values

Let us know your thoughts, too.

Posted in Interview Question, mkaram, Rant | 4 Comments »

Two new MVPs at ITWorx

Posted by archworx on January 2, 2008

This is just a small post to say how happy I am that ITWorx has 2 new MVPs:

1. Marwan Tarek (The great Sharepoint expert and MVP)

2. Myself (I am extremely happy about this)

This is just to extend thanks to all the people who gave us help and support at ITWorx and at Microsoft. You guys have been great to us, especially, Mohammmed Karam (our commander and cheif 🙂 ), Sherif El Touni (our best buddy from Microsoft), Mohamed Wahby (our great MVP lead), Ahmed Bahaa (my personal mentor) and last but not least, Mohamed Nar (our very cool Architect evangelist).

Also many thanks to my best buddy Mohamed  Meligy for his personal and professional help.

Thanks a million everybody, this has been a truly happy day, and looking forward to seeing many more MVPs from our beloved ITWorx. 

Posted in MSamy, Rant | 1 Comment »

Pandora’s Box: The Egyptian Software Outsourcing Industry Today – Risks & Trends

Posted by archworx on April 8, 2007

The Egyptian Software Outsourcing Industry is a relatively young industry. It is a very dynamic, growing, and changing industry. I believe that this year is going to mark a watershed period in the outsourcing industry across the world, and especially in Egypt. There are many tidal waves that are coming our way, and we’d better be prepared for them, otherwise brace yourself and take a deep breath, we may be about to sink.

The purpose behind these series of articles is to expose some of these upcoming risks and then open up the discussion for proposed mitigations or solutions.

 Some of these risks are very critical and we can’t afford to stand back and observe – we must be actively leading the market, on the forefront, trying out new innovative ways of survival.

Let’s start by looking at some of the changes in the world market one by one. This post will focus on local talent.

Competition: Attract and Retain me or die.

The wonderful thing about software is that you don’t need to be very resource-rich in order to participate in the revolution. All you need is some ingenuity and you can get very promising results. There are several garage-based developers who have toppled many industry giants in the world of software.

 This is the same reason why you get a lot of noise being made in places like Egypt, India and the Ukraine in the software field, where other industries cannot pick up momentum.

 This is an advantageous situation for many; in these countries Software Enterprises get a chance to thrive and compete on a global scale delivering surprisingly high quality software with minimal cost. Export your services, and you get international clients who are happy with your quality and thrilled at your cost model.

 This has created a multi-billion dollar software industry which has accelerated rapidly in many parts of the world; both in terms of adoption of the outsourcing model as well as establishing new outsourcing workshops.

Recently the competition around the world has become enormous, and it is now more and more a question of how you differentiate yourself.

With that introduction out of the way, it is time to recognize the real champion behing this multi-billion dollar revolution. The Software Developer. The Human Capital, Your core talent. Regardless of what they do exactly, if they write the code, test it, deploy it, support it, “infrastructure-it”, architect it, etc. This is the most important asset of any of these competing  companies.

Your building facilities are next to worthless, your computing hardware loses value faster than you can spell “depreciate”. The one most important factor is us. You are the driver of this revolution.

 Employers know this, and that is why there is always a tugging exercise happening behind the scenes to compete for resources – to compete for us. Employers are always battling to attract more resources, and to keep them by offering the highest possible package they can afford without compromising their cost model.

Competing for the Bottom Line

It is elementary that the reason why we may or may not be competitive is a factor of the quality of the software we deliver, and its price. This year in Egypt, our biggest threats are coming in the area of elevated packages that are being raised so high that they are going to blow the ceiling and threaten our cost model.

 Don’t get me wrong; I’m not advocating that we get under paid by any stretch – I am just voicing a loud concern about our long term sustainability.

 It has always been the case that IT services offered in a non-IT firm can sometimes get better compensated as distinguished and valuable inputs to the machinery required to operate in their specific market vertical. For example the telco market is sometimes able to better compensate IT individuals than a software firm because of many reasons – including the fact that they have much larger margins, and the fact that the bulk of their cost is not derived from these IT people – i.e. they can afford  to better compensate them without damaging their bottom line; their business model.

Say Hello

At the end of this first post, I will just conclude by asking people to welcome the new risks we are facing – the first step we need to do is to get acquainted with them, say hi, and then go back home and think about our next move.

This year we are welcoming a cash-rich telco operator in the market that is causing noticable waves in salary structures across the country.

As if that was not enough, there are strong rumours of two gigantic Indian Software companies that are setting up shop in Egypt with promised contract valued at several million dollars. The Huge Indian companies bring processes and operating models that are proven to work and will give them a significant advantage relative to local companies who don’t have similar experience.

This means more demand for your software person, with pretty much the same supply!

 So is that our risk I hear you ask?


Our risk is not merely that the salary structures are rising, and our hourly rates will follow them. Our risk is that this is going to happen so quickly that our deliverable quality will never be able to rise high enough to catch up with it. This is what is going to threaten your long term sustainability, and your pay check next year.

 Unless, we are aware of these risks and act accordingly…

See you next post.

Posted in mkaram, Pandora, Rant | 2 Comments »

Catastrophic Development: Reflections on the Union Carbide Industrial Disaster in Bhopal

Posted by archworx on April 2, 2007



This year marks the 22nd anniversary of the world’s most catastrophic industrial disaster at the Union Carbide plant in the Indian city of Bhopal. On the morning of December the 3rd, 1984, 40 tonnes of Toxic heavier-than-air Methyl-Isocyanate (MIC) gas were accidentally released to spread across the surrounding roads and streets in Bhopal in the Indian state of Madhya Pradesh.

Thousands of people’s lives were abruptly terminated. The entire city’s transportation system was brought to a standstill, worsening the situation further, as many people were trampled while trying to flee.

People woke up to find their bodies burning, their family suffocating, and ran out to the streets to escape, only to find that those before them who had been blinded by the gasses and were aimlessly rushing in unknown directions eventually collapsed to the asphyxiation of the mortifying gasses and died, lining the streets in piles.

The effect of the gasses rolling out of the holding tank eventually injured from 150,000 to more than half a million people, and the death toll reached 15,000 people. Many sources confirm that contamination is still present in the region.

The damage from the gasses ranged from respiratory diseases, blindness and skin diseases, to reproductive problems.


  • “There were thousands of bodies. There were bodies everywhere. And people were dying all round.”
    • Mohammad Owais, a volunteer at Hamidia Hospital, Bhopal, India



The Causes of the World’s Greatest Industrial Disaster

In the investigations that followed this disaster, the catastrophe was attributed to many factors, tragically, all of which did not have to happen, and were completely preventable. These included:

  • Lack of preparation for this sort of problem. No action plans were available for emergencies, and no contingency plans available to mitigate risks.
  • Reports issued months before the disaster predicting something of this magnitude would happen, and they were summarily ignored and never presented to senior management.
  • An Audible External alarm that was sounded to warn residents in the early morning hours, was quickly silenced – to avoid causing panic to residents.
  • The gas burning exhaust tower that allows gases to burn off before escaping into the air was inoperational, waiting to be serviced.
  • Doctors and Hospitals were not informed of the risks of MIC inhalation, and of its treatment methods – so they simply administered cough medicine and eyedrops to their patients.


  • “We have to travel at least two kilometres to get clean water… My health is so bad that it prevents me from carrying the water I need from there.”
    • Hasina Bi of Atal Ayub Nagar, a neighbourhood in Bhopal near the plant

How is this related to what I do?

You might think that this is very remote from your daily line of work. This is a problem in a different industry, a chemical plant, so far away from me, in an Indian city whose name I can’t pronounce, by a company I’ve never heard of before.

That’s the problem. The entire statement above is false. The difference in industry is immaterial, Union Carbide’s now infamous name has become immortalized down the industrial hall of shame. There are people who rally against Union Carbide, and its new owner Dow Chemical every year on this anniversary, all over the world. India in this case represents exactly what Egypt does in terms of attractive labour-cost and more fundamentally, lack of attention to audits, risk awareness, reviews and safety measures.


  • One reason, according to the Canadian Law Professor Jamie Cassels, who has written a book on Bhopal, is “the unwillingness of the industrialised countries to forego the competitive advantages offered by the less developed world.”

Unlike a Natural Disaster (like an earthquake, volcano, tsunami or the like), Industrial Disasters are caused by mankind. The fateful truth is that more often than not, they are caused by varying degrees of negligence and ignorance.

Let’s look at some of the root causes of this calamity listed above, and examine them with an eye critical of behavioural traits in our human culture. In our society there is a tendency to ignore “safety nets”, measures taken to ensure completely smooth delivery are often thought of as being a luxury – if you can just barely get it through the deadline, then you’re a genius. Remember what happened a few weeks ago when the fire alarm sounded 10 times in the company? How did we react? Do we know why it did that?

There is an obvious trade-off between risks-assumed versus quality-expected in every human endeavour. If you are driving a donkey-cart on a side road, some may say its okay not to have to tightly pack your payload on to the donkey cart. What’s the worst thing that could happen if you drop something? You go back and get it!

If you are on the ring road, and the car in front of you all of a sudden drops a traveling suit case in the middle of your lane, you probably won’t live long enough to explain to the other car’s driver how dangerous it is to travel without securing your payload first.

The reality is, if the project fails, the client will never appreciate the shortcuts you took to save them the extra mile at their expense when in reality the client’s safety is being jeopardized. Sometimes people think that developing software in a Professional Services firm such as ITWorx is a relatively safe enterprise – and that no bug (or fault) can hurt anyone. On the contrary, we are conditioned to think that avoiding “extra” safety procedures pays off.

Here’s what you could typically hear the root causes to the disaster being dismissed:

  • Lack of preparation for this sort of problem: “Yaa Raagel, this thing happened only once in India, Kabar Dimaghak!”
  • Reports issued months before the disaster predicting something of this magnitude would happen: “Maho this is the way we’ve always done business, would you just shut up and go on with your work?”
  • An Audible External alarm that was sounded to warn residents in the early morning hours, was quickly silenced – to avoid causing panic to residents: “Why make such a big fuss about something? How bad could it be anyway? What does an early warning mean by the way?”
  • The gas burning exhaust tower that allows gases to burn off before escaping into the air was inoperational, waiting to be serviced: “It’s okay, maho nothing usually happens anyway – we rarely use it!”
  • Doctors and Hospitals were not informed of the risks of MIC inhalation: “Da Kalam? You want me to go around scaring the Doctors about something they don’t need to know about? Even if I tell them, they won’t understand. Just shut up.”

Software faults can actually be fatal. Software Bugs can kill you, they can squander all your money – wasting millions and millions of it – they can put you at great disadvantages in the institutions that rely on systems full of them, they can waster your time, or merely inconvenience you.

The point is, the larger the project you are undertaking, the higher the risks. Sometimes taking shortcuts is not an option.

Big Boxout: Am I a Catastrophic Developer?

  • This section asks several thought provoking questions about the way we conduct business in the computer science arena and how that will influence our delivery standards. Take a moment to think of each of these questions carefully.
    • Do you manage transparently?
      • Do you keep “sensitive”, “important”, “privileged” or “interesting” information to yourself first before sharing it? Do you often conceal this information unwillingly due to time constraints? Do you make an active effort to pro-actively share such important information periodically with your team? Do you hold yourself accountable on how transparent you are? Do you teach your team what you know, or do you just do the important parts yourself, because it takes less time?

        Do you manage from an ivory tower not really knowing what your team is doing because you’re too senior?

      Do you Version your deliverables?

      • If I asked you which version of your software was installed at the client’s location, would you be able to give me an exact number? Would you be able to reproduce that numbered version from your source repository to match the version at the client’s byte for byte? Would you be able to guarantee that for every version “number” there would be one and only one actual version associated with it? Can you tell the difference between each minor feature adjustment or bug-fix? Are your release documents updated to reflect changes?

      Do you conduct full traceability on all dimensions of your project?

      • Do you think they are a waste of time? Do you know that they are the only way to scientifically prove the completeness of your deliverable? Do you know that without traceability you have no way to securely guarantee scope completion?

      Do you Unit Test your work?

      • Do you use a good unit-testing check-list? Do you know that ITWorx has a recommended unit-testing check-list? Do you know that the developer is the one who is supposed to run these tests before submitting their work for testing? Do you just deploy your code to the testing server the minute you think its finished and leave it those testers to find out if it works or not – because that’s what they’re job is anyway?

      Do you conduct proper, full audits?

      • Do you intentionally mislead auditors or give them half-truths? Do you conduct Mechanical-Audits? Just asking questions without searching for hidden truths? Do you understand why the auditor visits you? Or do you hate their guts? If the auditor asks you a seemingly useless question do you pray that they disappear or do you raise your concern with them?

      Do you communicate properly within your team?

      • Do you pause after you make changes and ask yourself “which stakeholders does this change impact?” and then notify them? Or do you often wait until one day a group of team mates starts screaming and yelling about fundamental changes that have been done behind their back?

      Do you give your Risk Management plan due dilligence? Do you keep it updated?

      • Is your risk management plan just composed of “Volcanos cannot be mitigated”? Do you periodically re-visit your Risk Management Plan to make sure that nothing new has surfaced? To make sure that you are increasingly ready for risks coming up on your radar?

      Do you re-invent or re-use the wheel?

      • Do you jump into developing first without looking to see if what you need has already been done? Do you seek to learn from the experiences of your pre-decessors? Do you ask yourself what others have done before you? Or do you prefer implementing from scratch? Every single time? Do you broadcast good ideas that you discover? Do you institutionalize reform and change? Do you contribute to re-use repositories?

        Do you keep the improvements to yourself, and end up being the only one to benefit from your lessons-learned?

      Do you review your work?

      • Do you peer-review your designs? Do you check that your packages actually install? Are spelling mistakes important to you?

      Have you considered emergency procedures?

      • Do you have plans to support your clients with high severity issues? Do you not think about this because it is not mandated explicitly by anyone?

Boxout: We’re Doomed – I can’t do anything about these problems!

  • If you’ve read some of the questions in the “Am I a Catastrophic Developer” panel, you probably guessed what the right answer we are hinting at was. How can I avoid disastrous development given cost-constraints?
    • Here is a simple recipe to managing risks in a way that safe-guards you against catastrophic development:
    1. Take a minute to think of this – and make your own decision. Ask yourself: “Do I want to be part of a project that will produce a potentially catastrophic development?”. Set your own standards.
    2. When you make your decision – make a point of taking time out every day – give yourself a minute to think of any major risks you may have glossed over today. Is there any one that your work today may impact negatively, either today or in the future?
    3. Make sure you are always current – new risks and new solutions are identified every day in our dynamic industry. It is your prerogative to make sure you are always current with technology.
    4. Learn how to make balanced decisions to deliver efficient risk management, and if you don’t know how to handle a specific situation, don’t just leave it – share the risk transparently with those responsible in your team and take educated decisions, even if you need to consult the client. Your experience will only grow by observing and asking mentors to give you their experience too.
    5. Finally if you are asked to blindly work on Impossible Situations where catastrophes are imminent without transparently communicating links to all stakeholders (including the end client), then make your own judgment call – are you going to be a part of the catastrophe, or the mitigation?


The Obligation to Fight Catastrophic Development is everyone’s responsibility. If you don’t, you bear on your shoulders the responsibility of potentially bringing harm on to others, perhaps very grave harm. The irony is that you can be a very hard worker, and yet by ignoring certain precautions, you can still be a catastrophic developer. One can only hope that we are always alert and aware of this fact. Our only defense against this is to continue to seek to be armed with knowledge, alertness and integrity.

Boxout: References

For further information, please browse these links out. Please note that the content in these pages can be deeply disturbing.

Bhopal Disaster:

Software Related Disasters:

This post was originally published in ITWorx Insite (April 2007).

Posted in mkaram, Rant | 28 Comments »

Do you know TED?

Posted by archworx on March 9, 2007

There is something called the TED conference, held annually in Monterey, California, which brings together a very high-powered audience of technology big shots and an amazingly diverse set of speakers. Check it out, they have a blog and usually have clips of the talks. I have heard it described as the single most interesting way that a smart and curious person could spend a week.

Posted in Nader, Rant | Leave a Comment »

Personal Capability Maturity

Posted by archworx on February 11, 2007

So I’ve been thinking about classifying candidates for interviews, or even team mates and colleagues at work according to their capability, for some time.

Disclaimer: Before you go on – please note this isn’t to establish workplace supremacy, but instead to enhance communication between team members!

Sometimes you’re sitting there talking to someone who seems to be spewing out jargon without really understanding what the underlying implications are. Other times you can discuss a topic with someone and find out that they’re trying to convince you of a solution that is so advanced you can’t readily grasp it!

So I’ve come up with the following theoretical model to classify people according to their vocational performance. I think this kind of classification is very important for each and every one of us. This isn’t so we can gain fake karma points or establish supremacy of any sort; but instead to know where one stands and what challenges you need to overcome in order to advance your career. This goes back to the post about reverse-engineering success, if you still remember that.

It is also important that you consider this model in terms of how to deal with co-workers. The most important aspect of industrial development is team work. A team can never work with dysfunctional communication, so you need to use this measure all the time in order to use the right tools to communicate with different calibres within your team. If you don’t immediately identify your team-mates specific capability at the start of a conversation you risk wasting the time the rest of it is about to take.

Back to the theoretical model I was talking about earlier, let me take you through its different levels, and we’ll be getting back to this every now and then as we work with answers to interview questions, and find out where the proper balance between pragmatism and ingenuity is achieved.

Here is the model – keep this in the back of your head the next time you work on a technical puzzle; I will call this the “Mkaram Intellectual Capability Model”, blatantly stealing prevalent industrial nomenclature (thank you CMU/SEI/DoD):

  • Level 0 – This is when you are totally stumped, you have no clue, and you can’t even start to address the question
  • Level 1 – Someone asks you a question and you start babbling for a few seconds, being mostly incoherent for some time until finally starting to mildly approach the problem with a mediocre solution that may be buggy or stands a marginal chance of working
  • Level 2 – You are asked a question, which may or may not take you a minute to think of, but you end up giving a perfectly functional framework for a solution that will work, and will do so elegantly
  • Level 3 – You give the question a moment of thought, and either leverage powerful solution patterns that you know inside out by virtue of how well you’ve worked with and thought of them previously, or challenge yourself to come up with clever shortcuts (because you know innately that they almost always exist for every problem). In either case your end solution is not only perfectly functional, but also covers new ground in terms of efficiency, elegance or otherwise.

If you combine this theoretical model with the 80/20 rule, that only 20% of your work is where 80% of the most critical application time is executed, then you should work as hard as possible to make sure your baseline never goes below Level 2 (or change your industry), and in fact, continuously push yourself towards Level 3.

As an extension to the disclaimer above, note that these levels are dynamic and relative, instead of absolute. Your own personal level can vary greatly according to how well you know your turf!

Posted in Interview Question, mkaram, Programming, Rant | Leave a Comment »

Reverse Engineering Success

Posted by archworx on November 13, 2006

Disclaimer: Not a Tech Post

I was reading this ( post by Scott Adams when I remembered a strange concept I came to realize a few years ago…

Basically, in Scott’s blog post he discusses a simple idea, that when he set his mind to reach a certain goal, he made it. No matter how seemingly difficult that goal was. For example he decided he would be the valedictorian of his class and he made it. He decided he wanted to become a successful syndicated cartoonist, and now he is the guy behind Dilbert.

If you think about it – it is a very powerful idea. Set your sights for incredibly high goals… and actually achieve them!

In reality, the idea of reaching success is not necessarily based on pure magic. Obviously there are a lot of factors that influence your journey, but the bare truth is that there is a lot that lies directly within your own hands that can greatly propel your progress through life.

I’ll give you a quick example – I used to love creative writing, and thought I’d do well in my English classes at school, but I rarely got the A’s I thought I deserved. I realized one day that there was a fundamental difference between my style and my instructor’s style. One day, I decided to immitate his style, and to my shock, I finally got my long anticipated A.

I quickly dismissed this experiment as unethical, and more importantly to me, not self-gratifying, and never did it again for many years to come. I found happiness in writing in my style, not in Mr. Brown’s.

This same situation happened to me over and over again, until I finally graduated and started working in a software company. Most people who work in software services will tell you that the most important thing you need to get straight is your Software Requirements Specifications!

If you ignore what the client wants, and instead deliver what you prefer or think makes more sense, you’re booking a one way ticket out of the company. Yet, inspite of how easy this seems at first, the reality is that in the software industry, convincing techies to actually do what someone else wants is extremely difficult.

This post is just a primer about a set of thoughts that are spinning around my mind at the time being. It will probably take me a long time before I’m done with them, if I ever am. Today I just wanted to establish the crucial fact that success, in principle can actually be easily attainable if you have the end in mind.

Such a simple sentence, but believe me, it is this elementary deception that is the key difference between performing reasonably well, and delivering exceptionally stellar results.

Stay tuned for the next rant, and till then, make sure you understand your “requirements”!

Posted in mkaram, Rant | 1 Comment »