Search This Blog

Thursday, March 20, 2014

Our education system has fail us

Afraid of failure, our school system never encourage us to make mistake and learn from it. We have exam system where you will be punished by your failure. Exam has turn from assessment purpose to punishing failure. That makes the whole system focus on exam score rather than the meaning of education. I came across this quote from Martin Luther King which I fully agree with.

The function of education is to teach one to think intensively and to think critically. Intelligence plus character - that is the goal of true education.
Martin Luther King, Jr.

The result? I do not know about other industries but I do believe our current education system is the main culprit of many failed software projects. Almost in every software project I stepped into, I have to undo the team's mindset which they inherited from the school. I need to educate them to think intensively and critically to every single decision, not be afraid of making mistake because that is the only efficient way of learning. Let me cite some examples of how this has affected successful project delivery.

1. Project Status Report
- Almost in all failed projects, the cause of failure does not due to a single incident that happened over-night. How would these "symptom" not being picked up by the project organizations that were involved in the project? In most cases, they were not even reported by the project manager in his status report. It can be certain that the team would have been aware of these "symptom", for example, customer keep changing mind, too many work that almost everyone need to work over-time constantly, the quality of the code is giving problem to the progress and etc. Project manager might think that to report these "symptom" will reflect badly on him/her capability to manage the project, hence they were ignored. They do not want to get punished for reporting the problem. While the management also graduated from the same system, they will indeed "punish" any project manager who reports such problem. The management did not create an environment to encourage those "symptom" being reported. If attention were paid to those "symptom", solutions will be generated and no one needs to face the consequences. i.e project failure. Our education system has turn the status report from an assessment to a score card, no one want to see bad things in the score card.

2. Refuse to clarify
- Be it traditionally or even with Agile methods, I still see many programmer refuse to clarify the items in the specification document or product backlog/ user stories. They are afraid that the clarification action will make them looks bad, hence they are making a lot of assumptions by themselves on what actually those requirements mean. Again, they treated the clarification event as an exam rather than an assessment if their understanding of the requirement is correct. They are afraid of being wrong.

There are many more other examples where a project team/organization demonstrated these behaviors or habits that they pick up from the individual's education. They adopted certain methodologies (water-fall or Agile) simply because someone has used it and it kind of work. They do not think intelligently why and what a method work. When they started using it, they refuse to think that they might have understood the method wrongly. They just continue to do it the same way and hope for a different result.

There are much more on this topic that every project organization should think of. It does not means that you "implement" the Scrum Framework, using Extreme Programming practices means you are Agile. It is more than what meets the eye.

Wednesday, March 12, 2014

Programmer is not factory worker!

I am always proud to tell people that I am a software programmer, simply because a programmer's job required frequent exercise of both right and left brain. They constantly required to transforming abstract idea into concrete implementation. It's a job that would require both art and science skill. Hence it's not something that anybody could easily perform.

However, most of the software programmers are badly underrated; they are treated like a factory worker. It is not a surprise that most business people believe 10 inexperience programmers will always 10 times better than 1 experience programmer. So when they are looking at how to cut operation cost, they go all the way to create off-shore development centre. This is similar to manufacturers who setup factory at places where salary is lower.

Wait a second! Am I contradicting myself here? If every programmer is smart, then what is wrong with the off-shore development centre? When they are equally smart and lower cost, isn't simple math and economy suggests we should all do that?

Don't get me wrong, I am not against the idea of off-shore development centre. It makes perfect sense for any business to seek every opportunity to lower down their operation cost. What I am trying to say is, while the action has a valid reason, one must know the goal and core principle. I have seen such action give birth to certain mind-set that back-fire on the business themselves

1. Off-shore programmer, they are pay less, hence they are less smart. We cannot trust them with important task!
- This is a very common assumption in this whole off-shore development game, the result is, most inexperience programmer will end up transforming themselves into what other perceive them to be, they become/behave like factory worker. It is largely due to they are not empowered or being encouraged to be autonomy. They work like a machine operator and required high precision of instructions to produce a good outcome.

2. Communication with the off-shore developers will not be a problem since we have comprehensive documentation!
- There are still many people who believe in this statement. Most of them are experience and senior "management" level. They believe that document is a good and efficient way of communication. They truly believe that long distance communication challenges could be resolved easily using specification documents, email and min phone call. Although majority of them have participated the Chinese whispers game when they attended communication training.

I am supporting the idea to recruit developers from foreign country, but you may want to bring them to your work place so they can be co-located with the users. This will allow them to use the most effective communication tool "face-to-face" when come to understanding the requirement. On top of that, give them the equal respect as you will give to any professional. They are smart people!