Programming: The finest steel has to go through the hottest fire

As the college season is in full flow, I'm back to my philosophical self and I've something for my students... Last week, I was conducting the regular Assembly Programming practicals, where I'm supposed to teach students 8085/8086/8051 ASM programming. Now, as much as I love programming and finding solutions to problem, I also love another thing: Creating problems for others to solve... and even if I know the answers, I would never give away the answer... come what may!!

So we started with all the instructions, available registers and memory allocation. Somewhere down the line, we started with a program to multiply 2 numbers. Now, as simple as I thought it was, my students didn't seem to think the same way. I told them that repeated addition was actually multiplication and they affirmatively nodded their heads, but the program wouldn't just come out from them. After close to an hour and me giving them numerous hints, we were still stuck at the loop!! They demonstrated it easily in a single line of C or C++ or Java, but ASM wasn't just clicking. That's when I affirmed, "Don't worry, programming doesn't come naturally to anyone... We all learn it our own way!!" And the class was stunned, similar to what I've seen at my office's training sessions... and the next question most of the times is, "Then how does it come naturally to you ??"...

"The finest steel has to go through the hottest fire!"... I read it somewhere, but then that's what is true about your individual talents. A singer's voice, a painter's hand, a composer's notes, a poet's verse... all may be claimed to have come from God or by birth, but its the desire to overcome obstacles and practice is what makes them achieve perfection.

Programming is very much an acquired skill, just like most things in life. Even logic for that matter doesn't come by birth. As we observe others follow a pattern of doing things, we follow that same pattern. The more we do the same thing in a way that is acceptable to our intellect, the more it becomes part of our existence and more natural the action becomes. When we first learn to speak, we probably think its harder than anything we have done before. Now as we know to speak, its easier than easy. Same is with programming. The more code that we observe, the more code we write, programming becomes more natural. Whoever says that logic to solve problems came easy, is either boasting his own ego or hasn't thought logically about it.

I was at the vegetable vendor the other day, who was talking of a way to solve the Bihar floods which made some 20million people homeless. His solution sounded really promising and as I know him for some years now, I knew he was intelligent. Huh... I wondered if programming would come naturally to him. He had never seen or used a computer ever but had passed high school. So if he could find a solution, it would mean that programming (read: finding solutions) came naturally to him. So, while he was selling vegetables, I sat beside him and blabbered the same things, I had told to my students at that lecture, but this time it was in Hindi and avoiding most tech-words. While I was speaking, I didn't even know if he was listening... He was busy selling vegetables, with his ~10yr old son and the aunties that came by kept smiling while looking at me. After a while, I asked him if he could multiple 2 numbers, given the instructions I explained... He thought for a while, picked up a few ladies finger (those long green vegetables), which he represented as instructions and explained me a perfect program to multiply numbers, not just 8-bit or 16-bit that would fit in a register-pair, but a multiplication program that would store larger numbers in ordered memory locations... Wow... that was superb!!... Unbelievable and brilliant, I said to myself!! I told him real instructions like ADD r1 r2, MOV r M,  ... and I told him to use those instructions and make a program to calculate modulus of a number. Hmmm... he thought for a while, but this time couldn't find a solution. He asked me many questions though, which he thought would give him an answer... But alas, no solution was found!!

I went back home and realized that may be it is the mumbo-jumbo words that divert our conscious efforts to find a solution. It may very well be the emotion of success that stops us from continuing to find the next problem and its solution. My students had passed earlier classes with 90% and more marks and were among the best students academically in the city.  Did that success get to them ??... Whatever it was, I realized persistence to find an answer to a problem gave us much better understanding of ourselves... May be programming teaches us to understand ourselves better than the problem at hand!!

Microsoft's Seven Deadly Sins in Windows

I've seen a lot of Deadly Sins post from around the blogosphere and I've also seen the rants on Windows Vista. Both the stories somehow clicked and formed a connection in my head. There are a lot of other software/company that commits the sins, but we already have the eternal bash toy called Windows/Microsoft. So I take my cue at Windows and convey my anger on the BSOD, I just saw on my desktop!!

Introduction

For those who don't know much about "sin", its an act/feeling which is understood to degrade the human soul and distances oneself for serenity. Every culture/religion has a few norms and refer to these sins slightly differently. Thus, every developer/user may realize my views either as sin or as virtue. The following sins do not follow any specific order:

Lust (Latin: Luxuria; Hindu: Kaam)

Lust is when we work a lot to improve superficiality of software and that's good enough to lure a lot of people. Irrespective of how much hardware that lust requires, we are drawn towards good looks. Microsoft did just that and Windows Vista had DirectX 9 hardware as a requirement to view Aero. It got a lot of criticism for increased hardware requirement and more usage of RAM. In fact, Microsoft has to fight "Windows Vista Capable" and "Windows Vista Premium Ready" at the courts and even within its own walls!! All due to lust!!

Envy (Latin: Invadia; Hindu: Matsar ==> Jealousy)

If you know how Microsoft came up with the GUI, then probably you'll know something about it being related to Apple. When Bill Gates and friends, they saw the Mac's GUI, they got envious and jealous that the Mac looked better than Windows. It had better usability, better window management, better shortcuts... It was so good, MS copied and even named the damn things Windows 2.0... Windows 1.0 sucked at doing windowing and Microsoft only learned the game, when they really worked out their own ideas in Windows 3.0. They gave away the envy and got back to work!!

Wrath (Latin: Ira Hindu: Krodh)

Microsoft got very angry when it saw another company taking over the web. The other company was called Netscape and its browser was becoming more popular than Internet Explorer (IE). Netscape regularly criticized IE for its issues and Microsoft couldn't bear that it was being bullied by the underdog. Microsoft showered its wrath on the browsers, and bundled IE with Windows 95 OSR. The browser got stuck so much with Windows that Microsoft had a few legal lawsuits and Netscape dies with time. Even if someone thinks Microsoft wasn't to be blamed for Netscape's death, a sticker of a monopolist got stuck on Microsoft only because it got angry in the browsers war!! Now its always at a risk of trying to bundle something into the system

Greed (Latin: Avaritia Hindu: Lobh)

Microsoft could have easily sold Windows 2000 with some simple basic changes for home users. But it got greedy and continued to milk the 9x core. And they released something known as Windows Me. It was called by many other ugly names, but probably you can associated many other cardinal sins to this release.Primary it was a marketing reason why this version of Windows was released and its been a black spot in Microsoft's reputation forever. Greed never pays off!!

Sloth (Latin: Acedia Hindu: Moh ==> Attachment)

Microsoft's sloth with Windows XP was so much that it believed it has done the best it could and didn't want to do anymore than what is required. Thus, Microsoft was completely lost about what to do in next release. Even if they thought, they were thinking too many things. Even sending someone to the moon would have been cheaper than building Windows Vista that came after 5 yrs of XP. Sloth brought the downfall and people are so much attached to XP that Vista doesn't mean much to consumers.

Pride (Latin: Superbia)

With Windows XP's success of selling lots of copies quickly, Microsoft got proud of its success. Celebrating for too long and basking in the proud glory of Windows XP proved costly to the development of Vista.

Gluttony (Latin: gula)

Microsoft is currently working on Windows Seven (also Windows 7 or se7en). Gluttony is one sin I believe Microsoft could be doing with this version. Gluttony is the act of over-indulgence. Microsoft already released too many versions of Windows Vista. Windows 7 could just show the gluttony with Microsoft releasing even more versions. The "componentized" architecture could just be for selling different components of the OS at different prices. Although Microsoft promises Windows 7 to be leaner and consume less resources, it could very well be the basic version. Microsoft could be gluttonous by selling different versions at different times as well... Still there is time before Windows 7 will have a feature freeze and then we will really come to know what's inside Windows 7.

Conclusion

With this post I wanted to highlight some of the mistakes Microsoft has made with earlier versions of Windows. Hopefully none of these cardinal sins are repeated in Windows 7 or else the other alternative OS are really catching up and Windows may not have enough time to get back!!

I believe that its stupid to fanatically claim something to be the truth... So I may have completely misunderstood these sins or versions of Windows. But I just now remembered that the opposite of sin is faith, not virtue!!

Summer With OpenMRS... & that Life is not FREE

I haven't blogged for a few days and I haven't been able to follow the tech news and follow-up on emails. But today, I feel a bit relaxed and probably have something to share. I haven't talked about myself on this blog, but today may be a little bit of philosophy and personal adventure will come through this post.

I had applied to the Google Summer of Code 2008 for a summer job and I will be working with OpenMRS. To all my students, now you have to believe I'm a student... and Moksh guys/gals I'm still your "MEAN" software architect ;-). Just that along with my services at Moksh, I'll also be contributing code to open-source, and consider this post to be an introduction to OpenMRS...

OpenMRS is a free, open-source, Medical Records System targeted towards developing countries and mainly implemented in HIV/AIDS health-care. You can read the Overview of OpenMRS and I think the OpenMRS community has already done a decent job at its own introduction. Instead, I will talk to you why I'm contributing to OpenMRS.

I realized pretty early in my life that "Humans fear death". Although death is the only sure thing about life, we often forget its quintessential for life. But probably its the fear for suffering that's more deathly than death itself. I wanted to be a doctor after I passed out of high-school, just for the sake of treating people and making them realize the beauty of life. I dropped out to prepare for the State Medical entrance exams and it was in this year of self-turmoil that I learnt from a spiritual guru that we can change lives only through what we loved in life. I realized then, that I've loved computers and programming all my life and that my karma couldn't have been more appropriate to hug my love for computers as tightly as I could. In the following years, I learnt new paradigms of programming, new languages and better ways to write code. I'm still learning and pray to God that the learning never ends...

With the same love, I hope to contribute code to OpenMRS, in a pursuit that it helps change lives. My summer job is to make a "General Registration Module" and you can read the details here. My mentor for this project is Brian McKown and hopefully I'll follow his guidelines and be useful to the OpenMRS community. And along with the fun of contributing, Google pays me $4500 + certificate + Google swag for the 3-months (i.e. if I complete the project successfully) and $500 to my mentor.

I don't think the project I'm doing at OpenMRS is a life-changing contribution by itself, but I hope its a beginning. If we all do our minuscule contribution to a social cause, it can really change lives. We have taken life and what life has given us so lightly that we don't respect it. Our skills may be completely different, but its the desire that can help. Although OpenMRS is FREE, life is not FREE. Give back something to the world, which has given you the skills.

I will be regularly writing about my OpenMRS Module and OpenMRS in general. Please look into the project, contribute and offer advice to me on the project.

Practice & Preach On Programming Languages (Programming Lesson 3)

Before I begin this part, I have to apologize to all my readers (Mark, Arun, Steven, Nolan, Dilip and a few others) for not completing the series, "Programming Lesson" for which I had promised 7 posts. I did not get enough comments on the last 2, although there were over 5000 hits on each post. But yesterday I got an encouraging email, and hence the next few posts.

Once a mother & her son came to a Spiritual Guru with the complaint of her son that he ate too many sweets. She asked the Guru to tell her son that sweets are bad for his teeth & health. She expected that the Guru would give some solution to this problem. But after the Guru heard her issue, he said, "Please come back after a month and only then can I give you some solution". The mother agreed to the Guru's advice and thought that the Guru needs a month to create some special medicine. She left and came back after exactly a month's time.

After she arrived, the Guru called her son near him and said, "Sweets are good in some quantity, but too much of it will make you a slave of its ill-effects." Before the Guru could continue, the mother got a little perturbed and said, "If this is all you had to say, why did you not say it the other day?" The Guru smiled and said, "I craved for sweets myself and until I controlled that desire, I was not in a position to preach." Listening to these words, the child understood better than any medicine could have cured.

This story has an important lesson for anyone who leads projects or anyone who manages a team. In my experience, it can be rightly applied to the advice which a software architect or project manager will give to his team. Especially programming language choice is one of the sentimental issue that I regularly encounter. I do not consider it to be the most important decision, but for a lot of programmers it becomes an emotional issue. Like the Guru rightly puts it, most of the times we become slaves of a desire of ours and it clouds the correct choice and programming language selection is no different.

As a software architect, when I advise my team or counter-argue on a choice of language, I first make it a point to give an example project in that language. I have programmed pilot projects in over 20 programming languages and designed over 35 projects of varied scale. I consider myself to be a newbie, but I realize that every programming language has its advantage or disadvantage. And hence I make it a point to practice in that language before arguing for/against it. It definitely helps when people around you listen and give inputs. Most of the times after you have practiced it yourself, you are more confident about your own choices. Like they say, "The problem is choice".... Hope this lesson just helps simplify the problem.

Open-Source Hardware & Gadgets

I just read this article at the NYTimes about Neuros OSD, an Open Source Device (OSD) for digital video recording. Like the name suggests, the device is open-source in hardware and software. But when I look at all the hardware and gadgets I own, I can't find a single one which is open-source. Infact, most of the gadgets don't even have a proper manual. You have to open the box and look through all the chip ID and then hope that somewhere the chip manufacturer has left something for you to munch! Lets not talk about the software side of these gadgets... its even worse.

The NYTimes article is not the first time that I've heard about open-source hardware or read an article glorifying open-source. I have attended a few conferences on open-source evangelism and read quite a few books and articles on it. I have also looked closely at it as a business model as well. And that brings me to the question as to why isn't open-source hardware popular?

If you look at the word "open-source", its been applied at a lot of places. And not just in software or computing. Its been adopted in education, arts, automobiles and quite a few other places. But then its in these sectors as well where you can count open-source adoption on your fingers. If I have to say it bluntly, "Open-source is not human-like" and hence it's not popular. The open-source ideology in software may be gaining popularity, but its more so because open-source evangelism gets more media coverage. An evidence to this fact is that while I'm writing this post, I also read about McAfee not giving back code to open-source project as part of the GPL (GNU Public License).  And I'm not writing this piece as an open-source supporter. Instead, I'm here to tell you that open-source hardware has a few pitfalls as well.

Open-Source Starts Excitement

There could be two diametrically reasons for the excitement surrounding open-source. It could either be because its atypical (aberrant of  human tendency) or its very close to man being a "social animal". Whatever be the reason, open-source does provide excitement. This excitement means you get more eyes to your project and more hands to help you expand the project. All of this means, you have an opportunity to sell your product. Open-source gadgets allow more people to tweak and play with it and in-turn the company sells more of the gadget. The user of the product also gets additional enhancements made by other users. Open-source is educational for the geek as well as more usable for the novice.

Whose Opportunity

So all these are good for the product that is open-sourced...right? Not completely. Didn't I just say its an opportunity to sell your product? But it is obvious that anyone with better manufacturing capabilities can have an even better opportunity. For hardware manufacturing, we all know China, Taiwan etc. can make it cheaper than others. The hardware that you designed and manufactured in another country can be easily replicated and sold cheaper. Currently closed gadgets are copied and sold cheaper. If your hardware is open-sourced, its infact an open-permit for the other to copy.

This is probably one of the main reasons why open-sourcing hardware/gadgets is not popular and never will be. Other reasons could be security loopholes, not-so-great designs, upgrade markets, dumping old components in newer models...

But this hasn't stopped open-source hardware to be released. There are many examples of open-source hardware and the list seems to be growing every month. Some popular open-source hardware projects include OpenSPARC (CPU), LEON (CPU), S1 Core (CPU), Simputer (Handheld), PLAICE (flash programmer), OpenCellPhone (Mobile Phone), AstFin (Telephony hardware), OSCar (Automobile), gEDA (Electronic Design Automation tools), Daisy (mp3 player), OpenStim (Brain Stimulator) and many many more.

Bad Never Happens to Good People

I can't forget the argument a student of mine gave in support of open-source. He said that "Atleast my contribution is changing the world"... And then another said, "If that contribution can earn you your bread..."... and I just smiled...

WYTIWYG - The Challenge of Custom Software

What You See Is What You Get (WYSIWYG or 'wizywig') is probably the best thing to happen to desktop publishing or web authoring. WYSIWYG enables you to view your output while you are making the stuff. A nice paradigm to put your creative ideas to paper. Thanks to the GUI Builder in RAD tools like Visual Basic or WinForms or netBeans Matisse, this WYSIWYG paradigm is brought to the developer as well. But these GUI Builders only cover the part where you are designing the GUI. What about the part where you are designing the business logic, the real things that get done in the background ?

I was recently working on a project that would enable a client to publish his magazines based on what data is stored in the database. It was kind of a report generation software, but with lots of automated formatting based on the database content. Like if the article was about a horse, it had to be taken from the database and formatted in a specific way whereas if it was about the jockey, then it would have a different formatting. The client had fully imagined how the magazine would look like and how the pages would be formatted. But we as developers had to meet the challenge of trying to sketch what the client was imagining. We were trying to give the client what he was thinking... We were supposed to say, "What You Think Is What You Get" (WYTIWYG) !!

I'm sure as creative minds we have always faced this challenge of taking someone's imagination and putting it to life. When it's your own imagination its easy to execute but when you have to understand and convey someone else's imagination it really gets complicated. And software development is all about meeting this challenge.

UML 2.0 has 13 diagrams and each of them are used to covey that imagination, but how many times have you come to new project and even after looking at all the diagrams, never figured out how to go about it from there?? And when you have a quick deadline to meet, it gets even tougher.

But during the above mentioned project, I realized that WYTIWYG is more about marketing than it is about true development. The reason I say this is because quite a lot of times, if you have good convincing skills you can change the way your client is thinking. This implies that you can always make someone else think what you want them to think. I guess some intellectual said, "You can take the horse to water, but you can't make it drink"... I would dare to disagree and say that if you have the skills you can make the horse drink as well...

May be some day we'll have AI so strong that the computer will be partially able to understand what we are thinking. May be after it's understood our thinking, it can create what we are thinking. But until that's done, improve your convincing skills... most probably, it'll be more useful that all your programming skills...

Programming Lesson 2: Switch On Switch Off

Thanks a lot for the emails that I received as replies to the previous story!! In the previous lesson (You are the bug. You are the solution), we talked about how thought process creates bugs and how it can be reduced. This is second-part of the seven stories that I'm going to use to improve programming skills

Programming Lesson 2: Switch On Switch Off

Two monks were traveling together, an older monk and a younger monk. They noticed a young woman at the edge of a stream, afraid to cross. The older monk picked her up, carried her across the stream and put her down safely on the other side. The younger monk was astonished, but he didn't say anything until their journey was over. "Why did you carry that woman across the stream? Monks aren't supposed to touch any member of the opposite sex." said the younger monk. The older monk replied "I left her at the edge of the river, are you still carrying her?"

The story is a great lesson that teaches us how to switch between different projects. The old monk breaks the rules of his religion, but then he doesn't carry that event of his life through him.

When we are working on a project, we need to think only about that project and what it requires. Objectivity is the keyword here and extremely important to understand what goals we wish to achieve. We can bring all the nice features of our previous project and add them to our current project, but we need to understand what we wish to achieve with our new project. Just bloating every project with every innovation that we have done till date doesn't make much sense!!

But the lesson in the story is not to forget the past. Past success & mistakes teach us lessons, but the idea is not to be affected by those success or failures of the past. Also, we all play different roles in projects. Sometimes as a developer, sometimes database designer, sometimes tester on the same project. We need to objectively play each role and behave in a non-attached manner on all these roles.

For eg. My 2 current projects on MobileATM and Distributed Video Encoding, both require network optimization and peer management. But the requirements and devices on the projects are completely different. If I were to be attached to one technique that I discovered for intelligent load management and use the same in both the projects, I know either of the project would fail miserably in performance and scalability.

So the lesson to be learnt from this story is of detachment and to be unaffected by past success and failure. We need to learn to Switch On-Switch Off between different roles that we play. And this does not just apply to programming, but to life itself, where at times we are parents, friends, colleagues, students, kids...


* Here unaffected means "remembering & feeling" but not lingering and doing actions based on those feelings

Programming Lesson: You Are The Bug...

There are a few things that inspire you, that make you think, that give you a new outlook. Somethings that help you introspect. And programming for me has always been the combination of all of the above things. Programming is what you could call, my way of praying or praising God.

This post is not completely technical, but I'm somehow compelled to share it with all my colleagues, friends, students and all those who read my blog. And I add some analysis for my project teams, so they start believing that software is equally philosophical as much its technical.

Programming Lesson 1: You are the bug. You are the solution

There was once a monk who would carry a mirror where ever he went. A priest noticed this one day and thought to himself "This monk must be so preoccupied with the way he looks that he has to carry that mirror all the time. He should not worry about the way he looks on the outside, it's what's inside that counts." So the priest went up to the monk and asked "Why do you always carry that mirror?" thinking for sure this would prove his guilt. The monk pulled the mirror from his bag and pointed it at the priest. Then he said, "I use it in times of trouble. I look into it and it shows me the source of my problems as well as the solution to my problems."

A lot of developers are great at writing code. They are really good at getting the results. A lot of people whom I've taught programming think that getting the desired output is the goal of writing programs. Thinking objectively is great when you want to finish the project, but when the bugs start calling, thinking philosophically is the best thing to do. And the first step is taught by this story!!

Realizing that the bugs appeared in the program, due to some thought process during the time of writing the program is the first step to improve as a programmer. I always ask everyone to have a bookmark of what's coming to mind when problem solving. The bookmark can be either on a piece of paper or in your mind. Later, whenever you find bugs, try to correct the thought process first and then the code. Understand that you have written the bug yourself, and "Unlearn the Learning". Forget all that you know about the program and start over again on the module with a different thought process!!

My reflective mirror on programming is the JavaVM/OS (with garbage collection) which I had written for my BS project. It ran Java programs on a microcontroller with 8KB memory and I implemented a robot on it. It was my masterpiece of art but it's a mirror that tells me I have to build things that are useful/understandable not just to me, but others.

You can have your own reflective mirror that tells you what you do wrong. Use it positively and learn from the good things and not so good things that "you thought"*, you created!!

Update: This was initially supposed to be a single post with 7 stories, but I realized that its going to be longer than comfortable to read all the posts. So I'll continue with a new post for each story

Part 2 - Lesson 2: Switch Off-Switch On

* - thats a different philosophy all together