Having been a newbie software developer (and I’m still fairly “new”), I did not understood why software developers in our company are quitting. Having been a fresh graduate, I was, then, still amazed by the fact that there are people out there in the real world that will pay me real world money just to write code – a hobby that I will do for free. I was puzzled. We are working in an environment that fosters creativity and innovation, a company that strictly subscribes to the “programmers’ bill of rights”, and a company that scores high in the Joel Test (11/12).  Those, plus the fact that we can surf Facebook anytime and drink all the brewed coffee in the pantry, made me believe that this is the best company to work for locally; it made me believe that anyone leaving our company is insane.

Just a few months after starting my job (I had my internship there for 6 months), one of the bestest programmer I know (he’s actually a “software architect”, but hates being called one), my mentor when I was still an intern, filed his letter of resignation. This guy is one of the most passionate programmer I know. He gets it. Paul Graham classifies him as a hacker and he actually worked for Microsoft (in Redmond, not the local whatever-they-are-doing-there branch).

For some, asking people why they quit their job is taboo; I actually enjoy having those type of conversation. Gives me insight. So I asked the fallen hacker, “Why did you quit?”. He pointed to the picture of his new born baby (his desktop wallpaper) and said with an enthusiastic smile “He is my new priority”. He then explained to me, in a fashion that I would understand, why working overseas means “better opportunity” for his family. Being a bit unconvinced with his explanation, I asked him “Is that all? Better opportunity?” and he replied back with a playful smile, “In my new job, I will be able to code again. I will no longer be a ‘Word Programmer’”. He has always joked about being a Word Programmer – programming in Microsoft Word using narrative texts (use cases, scenarios, etc) and UML diagrams; programming by story telling. He was indeed a hacker.

Having spent a year and a half on this job, I can say that I now have a vague idea on why programmers (or I.T people, in general) quit. Even though I’m only a year-and-half year old in corporate servitude, I had been handled by four managers and had been transferred to four teams and that gave me great insights on the crucial dynamics that affects employee turnovers. In my year-and-half stay, I have seen three managers, a project manager, two architects, four senior developers and a handful of intermediate developers go. Just a few months ago, four of my teammates left. The statistics above is a little off; it is more than 20%.

So why do programmers quit?

There are a lot of models that scientifically explains turnover, but most of them does not really cover the programmers psyche because most of them are written three decades ago. These models are not exactly wrong; they just don’t capture how programmers think and react.

So let me present to you my model. Let’s call it the Programmer Turnover Model. There are only two controlling variables on this model: Opportunities and Grievances. When these two factors achieve “equilibrium” (fancy word eh?), the employee will finally pull the trigger and call it quits. Seldom do I see or hear that a programmer quits just by one of these controlling variables; it is usually a combination of both. But it is not unheard of that an employee quits just because of opportunities or grievances: If you’re boss is verbally abusing (Grievances) you everyday, that is enough reason to quit.

Opportunities

Opportunities are the voice inside us that always yells “The grass is greener on the other side”. It is the greedy side of the human emotion. It is the human emotion that seeks larger paychecks and better benefits.

Programmers have all the incentives in the world to quit. In fact, if you want to suddenly increase your salary, all you have to do is quit your job and find another one. A 25% increase in salary between job hops is typical. In fact, most local programmers do it. You don’t even need to be highly competent to do this; you just need to impress the interviewers and pass the interview. In an industry that caters to outsourced work (typically boring business systems) and software maintenance jobs, the bar that is being set is not that high (not “Google high”). Fact of the matter is, most grown-ups (including my mom) advice I.T. workers to just “get a few years of experience and switch jobs”.

Local industry culture believes that the sooner you get overseas, the better it is for you. Those programmers that work or have worked overseas are perceived to be “successful”. And what better way to increase your chance working abroad than to beef-up your resume with “experiences”? Not only that you get larger paychecks and better benefits when hopping jobs, you also get a set of fresh credentials to put into your resume. When you work for a single company, you’re stuck with their technology. And in an industry where your skills are obsolete within five years (max), being stuck in a technology is a really really bad thing for you.

It seems that the game is rigged for the employers. Employers are nearly powerless in stopping the greedy side of human emotion. Aside for paying large sums of cash to these spoiled programmers, they incur the risk of losing expensive human capital. All hope is not lost, the human emotion provides some form of protection against job hoppers. The loving side of the human emotion.

A few moments ago, I made it sound that it is so easy to job hop. Well, it is for soulless programmers (and about half of programmers are). But programmers are human too and they possess some of that soft, caring, vulnerable human emotion. People just don’t quit their job out of greediness. They are attached to their officemates, they been used to the smell of that particular brand of brewed coffee in the morning, they love how their $5 dollar computer chair squeaks when they lean back while waiting for their programs to compile, they love those once-a-month company parties, they know their way into their programs and they’re quite competent in it, they love to see their crush on the opposite cubicle, they are considered the domain expert inside the department. Humans resist change because attachments are hard to break.

It is painful to leave a company and that is what stops most people to quit their job even if they know that there are better opportunities out there.

Grievances

Grievances are the devil’s advocate that whispers “Stop taking this sh*t and quit”. Opportunities provide all the incentives in the world to switch jobs and although the touchy human emotion tells us to stay because it is painful to leave, grievances makes it justifiable and easy to quit.

Grievances builds up over time that’s why it’s hard to avoid it. It stacks up high. Each person have a certain threshold on how high they can keep their grievances stack before it falls down and crumble (translation: Each person can only take so much bullshit).

There are many forms of grievances, but all of them contributes to the metaphorical grievances stack:

• My company is still coding in Cobol when there are better technologies available.
• We don’t have source control.
• My boss is a back-seat driver. His hobbies are micromanagement and micromanagement.
• The elevator takes forever.
• The air conditioner is too cold.
• The code base is so poorly written that it breaks in 27 different places when you add a single line of code. The previous developer maintaining the code base is a literal arts major.
• We are responsible for testing our own code.
• My teammates are bozos.
• I hate my project. It’s not fun and exciting. It’s grunt work.
• I have written just 150 lines of code in the last 2 years.

Grievances have many forms but grievances are simply things that gets listed down in the “I do not want” column of your employees checklist.

The good thing about grievances is that managers and employers can manage and control them. Unlike Opportunities where employers are powerless, Grievances can be managed and controlled. It’s not easy but it’s doable. And the first thing that needs to happen is communication.

If you’re an employer/manager working with programmers, understand that your programmers have all the incentives in the world to leave you for better opportunities. Do not make it easy for them by giving them reasons to quit.

The Price of Turnover in Software Development

In his influential book, “The Mythical Man-Month”, Fred Brooks emphasized the importance of Conceptual Integrity in software design and architecture:

Most European cathedrals show differences in plan or architectural style between parts built in different generations by different builders. The later builders were tempted to “improve” upon the designs of the earlier ones, to reflect both changes in fashion and differences in individual taste. So the peaceful Norman transept abuts and contradicts the soaring Gothic nave, and the result proclaims the pridefulness of the builders as much as the glory of God.

Against these, the architectural unity of Reims stands in glorious contrast. The joy that stirs the beholder comes as much from the integrity of the design as from any particular excellences. As the guidebook tells, this integrity was achieved by the self-abnegation of eight generations of builders, each of whom sacrificed some of his ideas so that the whole might be of pure design. The result proclaims not only the glory of God, but also His power to salvage fallen men from their pride.

Even though they have not taken centuries to build, most programming systems reflect conceptual disunity far worse than that of cathedrals. Usually this arises not from a serial succession of master designers, but from the separation of design into many tasks done by many men.

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

The conceptual integrity of software is a measure of how well software conforms to a single, simple set of design principles. When done properly, it provides the most functionality using the simplest idioms. It makes software easier to use by making it simple to create and learn.

Conceptual integrity is achieved when the software’s design proceeds from a small number of agreeing individuals. For software to maintain conceptual integrity, the design must be controlled by a single, small group.

When turnover is high, the conceptual integrity of your product is being sacrificed. And because conceptual integrity is the most important consideration in system design, having bad conceptual integrity will make your product hard to use. This in turn will affect your sales and eventually your bottom line.

Not only will the loss of conceptual integrity of your product negatively affects your sale, it will also affect the morale of your best programmers. High turnover rates induces the Software Peter Principle:

The software Peter principle is used in software engineering to describe a dying project which has little by little become too complex to be understood even by its own developers.

It is well known in the industry as a silent killer of projects, and by the time the symptoms arise it is often too late to do anything about it. Good managers can avoid this disaster by establishing clear coding practices where unnecessarily complicated code and design is avoided.

When your project becomes too complex to be understood by your best programmers, they will be naturally be forced to rewrite it. They will go into their manager’s office and ask for a re-write, the manager’s will then disagree because there are no “business reasons” to do so (and maybe they are right because “rewriting is probably the ‘single worst strategic mistake that any software company can make’”), so you’re best programmers go back to their cubicle grumpy and dives into the unmaintainable piece-of-crap that is your codebase. Soon, they quit (because there are better opportunities and you gave them enough reason to leave you).

The managers then instruct their H.R. people to hire a new software developer to maintain the unmaintainable codebase. But since the programmer is new, and inexperienced,  he makes implementation choices that work but have unintended negative consequences. Further degrading the conceptual integrity of your product; making it increasingly difficult to understand. It’s a death spiral.

If there is one thing that the best programmers hate other than maintaining crappy software, it is working with incompetent programmers. And because you have a crappy codebase and you need software “maintainers” to maintain your codebase, you hire cheap, incompetent programmers and that will send you down further in the death spiral. Paul Graham puts it nicely in his essay “What Happened to Yahoo!”:

Microsoft (back in the day), Google, and Facebook have all been obsessed with hiring the best programmers. Yahoo wasn’t. They preferred good programmers to bad ones, but they didn’t have the kind of single-minded, almost obnoxiously elitist focus on hiring the smartest people that the big winners have had.

Why would great programmers want to work for a company that didn’t have a hacker-centric culture, as long as there were others that did? I can imagine two reasons: if they were paid a huge amount, or if the domain was interesting and none of the companies in it were hacker-centric. Otherwise you can’t attract good programmers to work in a suit-centric culture. And without good programmers you won’t get good software, no matter how many people you put on a task, or how many procedures you establish to ensure “quality.”

In technology, once you have bad programmers, you’re doomed. I can’t think of an instance where a company has sunk into technical mediocrity and recovered. Good programmers want to work with other good programmers. So once the quality of programmers at your company starts to drop, you enter a death spiral from which there is no recovery.

Turnover reduces the conceptual integrity of your product. When there is no conceptual integrity, your product becomes hard to use and hard to maintain for programmers. The programmers maintaining the products hate the code so much that they quit. You hire new inexperienced programmers that further reduces the conceptual integrity of your product. You enter into a death spiral and you can no longer attract the best programmers because your code stinks. You enter another death spiral from which there is no recovery. That is the price of high turnover in software development: You lose your best talents then you lose your product and eventually your company.

How NOT to Retain your Best Software Developers and Programmers

One of the most popular form of “employee retention” is Training Bonds. Although it is not legally enforceable (or if it is but the company won’t really run after you because it is expensive to sue), most bright programmers will never sign a training bond. For most hackers, a training bond is a sign that a company is being ran by “suits”. Joel Spolsky attributes training bonds to “blind loyalty”:

I think that companies need to keep their employees loyal by treating them well, not by enforcing blind loyalty though a contract. I am not going to make the mistake of signing this clause again. Fortunately, with today’s shortage of qualified programmers, the balance of power today is sharply in your favor when you start a new job, and I think you have a very high chance of getting a job without signing restrictive employment clauses.

Another popular form of employee retention mechanism is counter-offer. Counter-offer is when your current employer gives you an offer (counter-offer) that is larger than the offer you received from the company you intend to jump to. Counter-offer is a big no-no because it sends the following message to your employee:

We have not really paid you the amount you deserve. But since we really need you to stay, we are willing to pay you more. We don’t think that you deserve this, but our hands are tied.

It is much worse when the news of a counter-offer leaks to your other employees. They will also feel that they are not being paid the amount they deserve, they will feel cheated and eventually quit. More turnovers, yay! Always remember the bribery never promotes loyalty.

If you think bribing your programmers when they accomplish something extraordinary will increase their loyalty: you are wrong. A lot of books have been written on the subject of incentive pay and why it is considered harmful:

… “incentives (or bribes) simply can’t work in the workplace”. DeMarco and Lister go further, stating unequivocally that any kind of workplace competition, any scheme of rewards and punishments, and even the old fashion trick of “catching people doing something right and rewarding them,” all do more harm than good. Giving somebody positive reinforcement (such as stupid company ceremonies where people get plaques) implies that they only did it for the lucite plaque; it implies that they are not independent enough to work unless they are going to get a cookie; and it’s insulting and demeaning.

I know that the title says “How to Retain your Best Software Developers and Programmers”, but I was only able to give the “How NOT to do it” guide. It took me a year-and-a-half to understand what motivates programmers to quit their job. It may take me another year-and-a-half to understand how to motivate them to NOT quit their jobs. You may wait for it, or you can just read Spolsky’s blog for a complete guide on how to manage and retain the best programmers that you will ever find.

When I was an Intern at a large Global 500 company, my major responsibility is to deliver a Software Delivery process that uses the software engineering practice called Continuous Integration. In simple terms, I am responsible for a project to create and setup a Continuous Integration Build Server that will be used to “build” the company’s products.

During those days, when I hear the word “build” or “compile”, the first thing that comes into mind is to press the F5 button. Ever since I started programming, when someone asks me for a copy of my program or if I need to distribute the “binaries” of my program, all I do is press the F5 button to create an EXE (sometimes with a DLL), then browse to the output folder(Bin) and copy the binaries. Suffice to say, that is my “Software Delivery” process however crude it is.

In College, I got a little bit more sophisticated. My major projects are all carefully packaged in a very neat MSI installer — but that is just for the major projects. Most of my standalone tools are still made using the “Press F5 button to build” method.

So you can just imagine my horror when the Software Architect presented me my task on my first day at work. I don’t know anything about Software Delivery, more so Continuous Integration. What is more scary is that I am expected to deliver my output in just 240 hours (my Internship duration). But thru the continuous support of the said Software Architect, I somehow managed to cram the concept of Software Delivery and Continuous Integration in just 2 weeks. Also, this book helped a lot, too!

Expert .NET Delivery Using NAnt and CruiseControl.NET

The build process that I created is quite simple and somewhat standard. However, there was a special requirement that the test harness be run on a different machine and that made the build process a little bit more complicated. This are the different stages of my build process:

1. Clean-up: Before starting a new build, delete all the previous directories (Source codes, Artifacts, etc.)
2. Fetch: Get the latest copy from the source code repository
3. Build: Compile the different projects
4. Archive: Tag the build then archive it
5. Test: Run the unit tests, measure code coverage and perform static code analysis
6. Feedback: Provide feedback by generating reports (with beautiful graphs!)

CruiseControl.NET Build History

The build process will automatically check for any changes in the Source Code Repository every 15 minutes, if it detects any change in the code, it will automatically start the build process. That is one of the advantage of using Continuous Integration — there is no need for a costly “Integration” phase.

In my previous blog posts, I’ve mentioned that I am working on a certain product that will be shipped later this month. Well, that project is nearing its completion. We now have a “Beta” build for our product and it won’t be long before an official Release Candidate is available.

During our weekly status meeting, I brought up a concern regarding how we are building our Beta builds that are being sent to the Test Department. Our current Build Machine (which is physically located locally) also acts as our Development Machine. All of the development activities like bug fixing are being done on the Build Machine. If you are REALLY REALLY careful, this is fine but still, a little bit crazy. But since we are Software Developers, we are never too careful. We are programmers, we cause accidents.

So why is it important to have a dedicated build machine? Here’s why.

1. Pristine – You want to keep the build machine as clean as possible to make sure that only the needed resources are being included in the build. If your build machine also acts as your development machine, keeping a pristine state is a very tough task. When I inspected our latest Beta build, I was shocked to see that there are *.pdb (debug) files included in the install image.
2. Control - It is very important to control your Build Environment. All of your builds must be coming from a standard setup from a standard state. The keyword here is standard. This means that the “exact state” of the machine used in creating Build 001 should also be used in creating Build 002. When you use your Build Machine as a Development Machine, it is almost impossible to maintain this “exact state” every time for every build. When we were migrating our product from SQL 2000 to SQL 2005, we added the SQL2005 installer to our local build machine but somehow, someone forgot to add the SQL 2005 installer to the source code repository. When we tried building from a new build machine, the installer would no longer work.
3. Reliability - All builds coming from the build machine must be Reliable. If you are using your Build Machine as a Development Machine, most often the not, your builds are coming from your local copy and not from the Source Code Repository. In most cases, this is okay. But in our case where the final build will be built using the official build machine (located in the US), this is a big problem. One of the problem that we encountered is that the local copy is not in sync with the repository copy. We are Humans, sometimes we forget to check-in our changes.

To solve the above problems (and since we don’t have any spare machines ), I used a Virtual Machine! Yes, I used a Virtual Machine as a Build Machine. After 3 days of fixing the build scripts and updating the unsync’d files, I was able to create a clean and working build from my VM Build Machine.

I'm a big VirtualBox fan!

Virtual Machines are perfect as Build Machines. You can always maintain a pristine state by creating a snapshot of a freshly installed setup build environment and always building from there. Everytime that you need to create a build, you can just rollback to that pristine state. This feature of build machines gives you control over your build environment. Since you are always rolling back to a pristine state, you will then be forced to always fetch the latest copy from your source code repository! This means that you can be confident the builds coming out from your build machine is always reliable.

Before, I have no faith in our source code repository copy. As a result, I am always too anxious in making sure that I don’t break the local copy. There’s always that constant fear that the official copy from the Source Code Repository is broken or the official copy does not reflect the local “tested” copy. Now, I am always confident that anytime, anywhere in the company, we can always create a clean and reliable build that will work straigth from the repository. That feeling is very liberating!

Do you know how much Programmer's Blood it cost to put this tiny sticker in a Software Box?

In my previous blog post, I’ve mentioned that I’m working on a project to migrate an entire product line to Vista. What I meant by that is that I am responsible for making sure that our current product will run properly on Windows Vista. To guarantee that it is indeed Running Properly it should behave *exactly* like it behaves in Windows XP.  In simple terms, my entire job security is riding on making our products compatible with Microsoft’s failed attempt at a MAC-ish Operating System and with Microsoft’s successful attempt (a first in their history) to make their operating system NOT backward compatible with older applications. So much for Raymond Chen’s camp undying obsession with backward compatibility.

This products that I’m talking about are a set of Web Applications written in ASP.NET version 1.1. This web applications are as old as Windows XP. I checked its File Modification History in our TFS repository and the last time that anyone have touched its code base is in 2005 — and that’s just for a minor code modification to fix a bug. I believe this apps were written way way back in 2004 — when I was in Third Year High School!

To make this products compatible with Vista, there are a couple of steps that had to be done. I’ll enumerate each steps and what it takes to accomplish them.

.NET Upgrade (.NET 1.1 to .NET 2.0)

Windows Vista comes pre-installed with .NET 2.0 (and .NET 3.0). Our products are running on .NET 1.1. One approach that most people will suggest is to just install .NET 1.1 on Windows Vista and everything will be perfect. Right? WRONG. Firstly, .NET 1.1 has already reached its end-of-life. Microsoft pulled support for .NET 1.1 last October 14, 2008. Although it was extended, its a sign that this technology is old enough to be replaced. Secondly, installing .NET 1.1 on a Vista machine is not as easy as you think. No, we are not lazy programmers, we just don’t want to introduce unnecessary complications to the system. We are, by the way, Software Developers.

Those Lazy Programmers

So the approach we took is to upgrade our Visual Studio 2003 solutions to Visual Studio 2005 solutions. This, in turn, will “force” the web application to use .NET 2.0. You might say, “How hard could it be? Visual Studio 2005 can convert old solutions automatically using its Upgrade Wizard. All you have to do is click next!, You lazy programmer!”. That’s correct. Upgrading the solution is no problem. Converting every file to .NET 2.0 compliant code is.

We encountered two conversion problems. The first one is relatively simple to fix. It’s a problem where the old .NET 1.1 Resource files (*.resx) were not converted to the .NET 2.0 resource files. The two resource file formats are different (the .NET 2.0 have a *.designer.cs component) and in very rare cases, the .NET 1.1 *resx files won’t work in .NET 2.0. This problem is very hard to catch since the incompatible *.resx files won’t throw a compile error. The strings just won’t be detected. But once found it was relatively easy to fix. After a day of investigation, we found out that the XML format for the resource files changed in .NET 2.0. As a simple hack (fix), we manually changed the <string> parameters of each .NET 1.1 strings to match the .NET 2.0 <string> parameters.

The second problem is harder to find and much much harder to fix. The problem is related to ASP.NET’s datetime picker control.

Our Calendar Control before upgrading to .NET 2.0

On our previous version running .NET 1.1, there is no problem with the datetime picker. But when we installed the .NET 2.0 version, the calendar objects are all over the place.

The Migrated .NET 2.0 Calendar Control

Two days of investigation later, we found out that the previous developer made this custom Calendar control by inheriting from .NET 1.1’s System.Web.Controls. During pre-render, he reads the rendered Calendar Control’s HTML and then does something funny with it. What he wanted to achieve is to replace the “Month” from the Calendar header (gray part) with a drop down box that contains a list of the months. So what he did is he “catch” the HTML stream from the Calendar Control and perform a String.Replace on it!

His Design Goal

The actual String.Replace command is something like this:

//szHTML = Get current HTML stream
//szCurrentMonth = Get current month from HTML
szHTML.Replace(szCurrentMonth, "
<select><option value="January">January</option>
       <option value="February">February</option>
       <option value="March">March</option>
       <option value="April">April</option>
       <option value="May">May</option>
       <option value="June">June</option>
       <option value="July">July</option>
       <option value="August">August</option>
       <option value="September">September</option>
       <option value="October">October</option>
       <option value="November">November</option>
       <option value="December">December</option>
</select>
 
");

It worked fine before the migration, but somehow we broke it during migration to .NET 2.0. A further investigation of the “emitted” HTML stream from the .NET 2.0 control shows this:

<table style="border-style: solid; border-width: 1px; border-collapse: collapse;" title="Calendar" border="0" cellspacing="0" cellpadding="2">
<tbody>
<tr>
<td style="background-color: Silver;" colspan="7">
<table style="width: 100%; border-collapse: collapse;" border="0" cellspacing="0">
<tbody>
<tr>
<td style="width: 15%;"><a style="color: Black;" title="Go to the previous month" href="javascript:__doPostBack('ctl01','V3378')">&lt;</a></td>
<!-- THIS WILL BE THE PART THAT WILL BE REPLACED BY A DROP DOWN BOX -->
<td style="width: 70%;" align="center">May 2009</td>
<td style="width: 15%;" align="right"><a style="color: Black;" title="Go to the next month" href="javascript:__doPostBack('ctl01','V3439')">&gt;</a></td>
</tr>
</tbody></table>
</td>
</tr>
<tr>
<th align="center" scope="col">Sun</th>
<th align="center" scope="col">Mon</th>
<th align="center" scope="col">Tue</th>
<th align="center" scope="col">Wed</th>
<th align="center" scope="col">Thu</th>
<th align="center" scope="col">Fri</th>
<th align="center" scope="col">Sat</th>
</tr>
<tr>
<td style="width: 14%;" align="center"><a style="color: black;" title="April 26" href="javascript:__doPostBack('ctl01','3403')">26</a></td>
<td style="width: 14%;" align="center"><a style="color: Black;" title="April 27" href="javascript:__doPostBack('ctl01','3404')">27</a></td>
<td style="width: 14%;" align="center"><a style="color: Black;" title="April 28" href="javascript:__doPostBack('ctl01','3405')">28</a></td>
<td style="width: 14%;" align="center"><a style="color: Black;" title="April 29" href="javascript:__doPostBack('ctl01','3406')">29</a></td>
<td style="width: 14%;" align="center"><a style="color: Black;" title="April 30" href="javascript:__doPostBack('ctl01','3407')">30</a></td>
<!-- THE TITLE ATTRIBUTE WAS ALSO REPLACED ACCIDENTALLY -->
<td style="width: 14%;" align="center"><a style="color: Black;" title="May 01" href="javascript:__doPostBack('ctl01','3408')">1</a></td>
<td style="width: 14%;" align="center"><a style="color: Black;" title="May 02" href="javascript:__doPostBack('ctl01','3409')">2</a></td>
</tr>
.....</tbody></table>

A comparison with the “emitted” .NET 1.1 control shows this:

<table style="border-style: solid; border-width: 1px; border-collapse: collapse;" title="Calendar" border="0" cellspacing="0" cellpadding="2">
<tbody>
<tr>
<td style="background-color: Silver;" colspan="7">
<table style="width: 100%; border-collapse: collapse;" border="0" cellspacing="0">
<tbody>
<tr>
<td style="width: 15%;"><a style="color: Black;" title="Go to the previous month" href="javascript:__doPostBack('ctl01','V3378')">&lt;</a></td>
<!-- THIS WILL BE THE PART THAT WILL BE REPLACED BY A DROP DOWN BOX -->
<td style="width: 70%;" align="center">May 2009</td>
<td style="width: 15%;" align="right"><a style="color: Black;" title="Go to the next month" href="javascript:__doPostBack('ctl01','V3439')">&gt;</a></td>
</tr>
</tbody></table>
</td>
</tr>
<tr>
<th align="center" scope="col">Sun</th>
<th align="center" scope="col">Mon</th>
<th align="center" scope="col">Tue</th>
<th align="center" scope="col">Wed</th>
<th align="center" scope="col">Thu</th>
<th align="center" scope="col">Fri</th>
<th align="center" scope="col">Sat</th>
</tr>
<tr>
<td style="width: 14%;" align="center"><a style="color: black;" href="javascript:__doPostBack('ctl01','3403')">26</a></td>
<td style="width: 14%;" align="center"><a style="color: Black;" href="javascript:__doPostBack('ctl01','3404')">27</a></td>
<td style="width: 14%;" align="center"><a style="color: Black;" href="javascript:__doPostBack('ctl01','3405')">28</a></td>
<td style="width: 14%;" align="center"><a style="color: Black;" href="javascript:__doPostBack('ctl01','3406')">29</a></td>
<td style="width: 14%;" align="center"><a style="color: Black;" href="javascript:__doPostBack('ctl01','3407')">30</a></td>
<td style="width: 14%;" align="center"><a style="color: Black;" href="javascript:__doPostBack('ctl01','3408')">1</a></td>
<td style="width: 14%;" align="center"><a style="color: Black;" href="javascript:__doPostBack('ctl01','3409')">2</a></td>
</tr>
.....</tbody></table>

Executing the String.Replace command in the .NET 1.1 code will produce the proper output. However, Microsoft decided to upgrade the Calendar control in .NET 2.0 by adding a tooltip for each date!

Tool Tip in .NET 2.0

Since the String.Replace has no checking (this is not REGEX afterall), it also replaced the “Month” in the tooltip with the drop down box (<select> command), thus generating the broken control shown above. This is not, in anyway, the fault of the original developer. Can you anticipate what will Microsoft do?

This is my first encounter on how Microsoft can break your products.

MSDE to Microsoft SQL Server 2005 Express

Our web applications were written before the release of SQL Server 2005 Express. The only *free* choice back then is Microsoft SQL Server Desktop Engine, a free scaled-down version of Microsoft SQL Server 2000. Since the support for MSDE officially ended last April 8, 2008, we are then forced to upgrade to Microsoft SQL Server 2005 express.

Our previous MSDE setup runs on default instance. In migrating to SQL Server 2005, we run the risk of “conflicting” with our other products that runs on default instance of SQL 2005. So the decision was made to migrate from default instance to named instance.

Migrating to SQL Server 2005 Express is straightforward at first look. The first and the most obvious thing to do is to modify the installer (InstallShield) so that it will install SQL 2005 instead of MSDE.  To compensate with the instance problem, the second thing to do is to modify each and every connection string in the entire app to point to the proper named instance. Making sure that each and every connection string in your entire app has been changed is a monumental task… especially if different version of connection strings were used. After that, you also need to modify the Service Query String so that it will point to the proper SQL Service ($MSSQLSERVER to $Instance_Name). There are also minor modifications here and there, but its not worth the mention.

After three days of manual modification, we got to the point where we were able to install the product. We tested it and everything seems to work fine. We then got to the part where are going to test for the database backup. Lo and behold, it failed. But no error message was given. We looked for the bug for an entire day but our search proved futile. We called it a day and went home. The next day, my brilliant manager excitedly told us the problem.

Microsoft SQL Server 2005 Express does not have SQL Server Agent.

Our backup routine uses SQL Server Agent. When a user request for a backup, the SQL Server will “schedule” that backup request and the SQL Server Agent will “execute” the request when the schedule parameter is met.

Simply put, No SQL Server Agent, No Backup.

We have three solutions to the problem:

1. Ship the product with Microsoft SQL Server 2005 standard or enterprise edition (Instead of the Express edition)
2. Remove the “scheduled” backup. Instead, just provide a “one shot” backup
3. Create our own custom “Backup Scheduler” using Windows Task Scheduler

We talked to the marketing folks and they eliminated option 1 because, according to them, we can’t make our customer pay for something that was free before. Option 2 was eliminated due to the simple fact that we can’t ship an upgraded version of our product with downgraded features (But this was actually done to one of the product that had missed its deadline). So Option 3 was our only choice.

The plan in creating Option 3 is simple. Create a “scheduled task” using schtasks.exe that will invoke sqlcmd.exe that will invoke the sql command to invoke the stored procedure that was doing the backups. The schtasks will then be invoked by the ASP.NET page using Process.Start();. So I created a wrapper class that will simplify this process. The class was created in 2 hours and I had it running and compiled to the ASP.NET page in just 3 hours. BUT IT DIDN’T WORK.

Further investigation revealed that IIS 6.0 has a different security model than IIS 5.1 (which XP uses). Spawning a process from within IIS 6.0 will have a credential of NETWORK SERVICE. Yes, we can impersonate since we are using Windows Authentication, but it won’t work unless we force the user to type-in the credentials again. Which is bad in a usability point of view.

The workaround was to put the scheduler on a Windows Service that will then be run with proper credentials. The problem then was the communication between the ASP.NET page and the Windows Service. How will the Service know when to invoke the backup? Our solution is a little crude but simple. We did it old-skul UNIX style! The ASP.NET page will create a “marker” file in a certain, defined location. The Windows Service will then monitor that location… waiting for the “marker” file. If the marker file is found, the service will then invoke the backup procedure. Fortunately for us, all the data needed for the backup is in the database, so we don’t need to pass anything between the ASP.NET page and the Service. We could have used sockets or mutex, but its overkill for our purpose.

This are just the major steps that had to be done in order to make our web applications compatible with Windows Vista. There are a couple of minor steps that also needs attention like the IIS 5.1 to IIS 7.0 migration and the new Vista Security Model.

The next time you see the “Vista Compatible” sticker on a Software Box, think of the programmers who nearly died in making your software run on a “cuter” operating system.

Windows 7, we are ready!

My First Official "Coding Horror" Encounter

Back in College, I have a friend who’s programming prowess is so godly that it can surpass or match mine . He is a C++ Junkie and belongs to the Java Cult. His mental agility is so great that he can beat me in writing complex algorithms anytime of the day. In fact, I chose him to be the “Architect” for our project in Compiler Theory Class (Kompayler Studio 2008: The First Tagalog Kompayler, Programming Language and IDE). He is THAT great of a programmer… BUT

Being a Great Programmer is not the same as being a Great Software Developer

“Aren’t programming and software development the same?” Uhhmm, NO. Programming is just a single part of Software Development. Software Development, on the other hand, is an entirely different song and dance.

In one of our converstations, I told him that instead of reading books about programming he should try to read books about software development. I gave him that advice not because I want him to suck in programming (I’m not that envious). I gave him that advice because I want him to realize that programming alone won’t make a great software product and that programming prowess alone won’t give him the best programming job around… at least here in the Philippines.

One of our main differences is reflected on how we write code (which eventually shows in our software). For example, say that we have a project that requires us to deliver a Simple Number Sorting Application that will ask the user to input 50 numbers and sort it. This project is resource constrained in such a way that we need to deliver it in 2 days.

What I would do is use a pre-existing bubble sort algorithm available in the class library (in .NET, I suppose), then I would add additional functionality, then create a test harness (unit test) to test my functions and then I’m done with the “coding” part. Then I would use the rest of my time to design an intuitive user-interface, provide a user manual and work on the packaging.

My Simple Sorting Application

On the other hand, my friend would create a complex multi-threaded sorting algorithm that will have a runtime efficiency of  O(Log N). Not only that, it will be written in Haskel (or any other hardcore programming language) and it will also be invoked via command-line! So hackerish.

His Complex Sorting "Tool"

My point is simple… In Software Development, there is a thing called Tradeoffs. What do I mean by Tradeoff? Take the above example. I traded-off the uber-cool complex multi-threaded sorting algorithm to USABILITY AND FUNCTIONALITY which, by the way, has more practical and positive impact to my users. You could argue that I suck for using bubble sort and not the complex multi-threaded sorting algorithm and you could also argue that my bubble sort has a runtime complexity of O(N^2). But being a Software Developer, I know that using that “complex multi-threaded sorting algorithm” would only be faster by 0.000000000000001312 seconds (remember, we are only sorting 50 elements) and that “improvement” will not be of any significant use to my end-users and I might as well use my time in creating extra  features, such as Print and Copy to Clipboard, that will surely make my product more functional and easy to use.

At work, I am working on a project to “migrate” our products to Vista. To Migrate meaning “to make it compatible with Vista”. One of our product has an Autorun executable which will decide which “components” (SQL Server, VC++ 8.0 Redistributable, .NET Framework) to install. During a routine test run at the Test Deparment, they found out that this certain product is not working on Vista and filled a Track against it. The said Track was assigned to me and I’m expected to fix it. So I pulled the Visual Basic 6.0 source code of the Autorun executable from our TFS and performed an investigation. While investigating, I saw a very weird block of code…

Private dim VCREDIST as long
Private dim NETFRAMEWORK as long
Private dim SQLSERVER as long
Private dim COMPONENT1 as long
Private dim COMPONENT2 as long
Private dim COMPONENT3 as long
Private dim COMPONENT16 as long
 
VCREDIST = 1
NETFRAMEWORK = 2
SQLSERVER = 4
COMPONENT1 = 8
COMPONENT2 = 16
COMPONENT3 = 32
COMPONENT16 = 65536

If you see a 1 or a 0 in the code, its pretty normal because you know that it is a flag for something . But if you see a 7 or 16 or 32, you know something is wrong. So I ignored that and went straight to the actual function that does the shell execution to install the component and I saw something like this…

While ComponentInstalled != 13
 
	installNum = GetNextComponent	
 
	if installNum AND 1 then
		InstallComponent(installNum)
	else
		installNum = installNum * 2
	end if
 
End While

I was dumbfounded and stupified, why is there an “AND 1″ in that code? and what is the purpose of the * 2? So I asked my manager for his input. And after staring at the code for 30 minutes, my brilliant manager shouted “That code is using BIT PATTERNS!“. Instantly, I understood what the code does.

VCREDIST = 1                 '0000 0000 0001
NETFRAMEWORK = 2        '0000 0000 0011
SQLSERVER = 4              '0000 0000 0111
COMPONENT1 = 8           '0000 0000 1111
COMPONENT2 = 16          '0000 0001 1111
COMPONENT3 = 32          '0000 0011 1111
COMPONENT16 = 65536    '1111 1111 1111

That block of code is actually a binary pattern used for flagging the components. Each placeholder in that binary pattern is a FLAG (1 or 0) which actually tells the function GetNextComponent if that component should be installed or not. The *2 is used for shifthing the binary pattern so that the active placeholder for a certain flag will be at the rightmost (last bit) of the pattern! Brilliant!

To solve the issue, I just needed to force the Autorun to Install VCREDIST in Vista by adding this line of code in the Vista Condition of the GetNextComponent function:

VCREDIST = VCREDIST OR 1

So it will always install the Visual C++ 8.0 Redistributable in Vista. The actual problem is that the Autorun Executable thinks that Vista does not need the redistributable and will not install it.  That’s why our product that needs the redistributable will not work.

I have great admiration for the brilliance of the programmer who wrote this. The method is so efficient that instead of declaring 12 Integers for Flag, he would only need to use a single long! My manager told me that the one who wrote this application is actually a “CONTROLLER” programmer. A type of programmer in our organization that writes the firmwares for our hardware controllers.

When writing firmwares that needs to be tight and needs to run in realtime, time complexity is your biggest enemy and you need to code against that. But in an Autorun application for installation, you DONT! In this example, Readability and Maintability was traded-off to efficiency that was not even needed! In turn, a simple issue that can be fixed in a matter of seconds was fixed in half a day.

As Software Developers, we should have the right mindset to decide on what trade offs are necessary. We should not only be Great Programmers who can write great codes but we should transcend to being Great Software Developers who can “take a concept, build a team, set up state of the art development processes, design a software product, the right software product, and produce it. Not just any software product: a high quality software product that solves a problem and delights your users. With documentation. A web page. A setup program. Test cases. Norwegian versions. Bokmål and Nynorsk. Appetizers, dessert, and twenty seven eight-by-ten color glossy photographs with circles and arrows and a paragraph on the back of each one explaining what each one was.”

As for my Friend, he is now working at Oracle. My only wish is that he would be able to work on their database management system where efficiency has higher value than code-readability.

“Congratulations in accomplishing another milestone in your life. Now, there’s a new milestone that you need to accomplish…”

I don’t get it. What’s with deadlines and software development? and why is it that most, if not all, developers I have met (or read their blogs) hate deadlines? and why is it that in the field of I.T in general, it is a common and accepted practice that projects overshoot and miss their deadlines? I know that’s alot of “whys”, but cut me some slack, will ya? I’m just 3 weeks employed.

During my college days, I love deadlines! I don’t know exactly why, but I saw it as a “finish line” that I need to cross — and if I cross it faster than anyone else, then I can be considered as the winner. And I’ve always won those races (as pointed out in my previous post). Maybe that’s why I love deadlines… they provide an arena where I can compete and win. And everyone who knows me can attest that I’m a very competitive guy who like to boast and win (and all real programmers are like this, by default). Pride of Workmanship, I say.
Just this week, my manager (Development Manager) approached me and told me that I will no longer be working on my Dirty Job (Localization, that is) and that I will be placed on a new project that involves ASP.NET and Licensing. Well, who would not want to work on a shinny cool new feature using an updated technology especially when it will take you off a dirty job? So I took it and became the main developer for the project. Anyway, Encryption and security stuff is right up my alley (My undergraduate thesis is related to encryption) and I have 2 years experience working with .NET code so I thought, the project is just appropriate for me.

The project involves implementing a new licensing scheme called Temporary Licenses. There’s already an existing set of licenses (READ: SET) that is too complex for me to explain in this post. But anyway, the reasoning behind implementing the new temporary license is to allow the Salesman (or the Marketing Guys) to demonstrate how the new product works and in turn, close the deal and earn some green.

My task, then, is to construct an Architecture Document to explain how the different components of this new feature will interact with the existing core system. Now, let’s take a step back and consider the fact that I am just 3 weeks old in terms of employment and then I am asked to deliver an Architecture Document! A high-level design document! That’s a huge vote of confidence coming from my manager and I’m very thankful for the fact that they are giving me an opportunity to flex my Programming Muscle very early-on. (Yes, I know its documentation but in-order to deliver this particular architecture document, you need to understand the underlying code of the existing system. Think of it like the foreplay before having sex. haha).

Right after reading the concept document (a document which contains how the higher-ups believe the new feature should work), my manager asked me for a guesstimate. So I said, “I don’t know“, and quite joyfully at that. How should I know? I haven’t even seen a single line of code of the existing system. Even though I know exactly how to implement the new feature, I still need to add it to an existing working system and integration needs research and time. Luckily, my manager is not a “suit” so he understood where I was coming from and scheduled a meeting with our Technical Lead and another Senior Developer to produce a valid estimate.

Eventually, my manager persuaded me that this task can be done in 1 week. By that time, I already have a vague idea on how to implement the feature in the existing system… I just have to prove my theory by directly working with the code so I agreed and started by asking for a debug build that I can work on. Sadly, there is no working setup for a debug build so I have to make do with just reading the code and compiling mentally. And doing it like that will take time — time which is not included in my prior guesstimate.

Now I know why developers hate deadlines. Deadlines makes developers feel that they are not in control of the situation. And as developers, we hate being out of control. We are so used to having TOTAL control of our own universe (Our Systems), that we already think that we are the Gods of our own universe. I remember a quote by Joseph Weizenbaum, the creator of ELIZA, that goes something like this…

Why do I feel that deadlines make us feel out of control? Well, in my particular case,  I feel out of control because I don’t have any command to the crucial variables that constitutes my task. Like, I don’t have any control on when I will have my debug machine. I also don’t have control on what time the people from U.S. and U.K will respond to my inquiries via e-mail. I don’t even have immediate control of my research time because it is dependent on having a debug machine and other people. The key word here is DEPENDECIES… and it plays a big part of making us feel out of control.

In my previous post, I have mentioned that TEAM WORK is my biggest learning I had from my On-the-Job training. But there is also some downside in working in a team environment and that is dependencies. After realizing this, something suddenly hit me. All throughout college, I have mostly worked alone (around 85% of the work) and that’s why I have total control of anything that is related to my projects and that is also why we have always submitted 2 to 3 weeks ahead of the deadline. Other teams have always submitted late (As much as 6 months late), and those teams are composed of friends or barkadas… Because they are so keen on working in batch (like overnight thesis making) that they ended up not finishing anything at all. Why? Because a MODULE that is supposed to be done by MEMBER A is not done in time so the other MODULE by MEMBER B cannot move forward because it is dependent on MEMBER A’S MODULE. This is the common excuse during their defense and I believe its a common excuse among I.T. students everywhere when asked why the project was delayed for so long — and it’s all about dependencies.

Back then, I used to love deadlines because it makes me feel that I am the master of my own destiny. I used to love it because it makes mo more productive by giving me something to shoot for… a competition, a race, a tourney to win…

… Now, I hate it because if I’m behind schedule, I feel doomed and depressed and unmotivated.

According to Accenture’s website, participants will “learn about key Accenture leadership contribution areas by being value creators, business operators, and people developers through seminars and fun activities… They will also hear first-hand testimonials from some of the top Accenture Senior Executives, Managers, and Leads from various workforces and projects”.

If you have attended at least one leadership seminar in your life, you know that it will be full of ego-massaging and morale-boosting talks from some senior-management guy from some Fortune/Global 500 company. And some funny “group dynamics” that the event coordinators will link to a certain “leadership” quality but in reality, it will just make you tired and sweaty. I have yet to attend a leadership seminar that will really teach me on how to be a really good leader. Accenture SLC… here’s hoping!

During my College days, whenever there’s a new project that had to be done in groups, people never failed to nominate me as the leader (Mostly on CS* and IT* subjects) and I have always gladly accepted it. I like being the leader because I have total control of everything… from the implementation details like naming conventions and algorithms to project management details like deadlines and task breakdowns. And looking back, I was very successful on all of those endeavors. Successful in the sense that we have always submitted 2 weeks (at most 1 month) before the deadline and the specs and feature set (Including documentation and packaging) of our project is above and beyond the agreed upon requirements. As my co-worker puts it, we may have “underpromised and overdelivered“. Truth be told, all of my project related subjects garnered a grade of 1.0. (Making a point here).

But it begs the question, why did my groupmates chose me as the leader? I don’t really know. But what I know is this… They did not choose be because I was inspirational, motivational nor because I have good leadership qualities… They chose me because I can deliver (and because they know that I will always do 85% of the work). They chose me because of my technical abilities and not because of my leadership abilities.

You know what? I don’t really think that I have “leadership” abilities. In fact, I suck at being a leader, or at least I suck at the people-side of being a leader. I do not know anything about being inspirational or motivational. I do not know how to handle a group efficiently. I don’t know squat about WBS (Work-breakdown Structure) or Teamwork. Up till the end of my college days, I have, mostly, always worked alone.

That’s why my biggest learning from my On-the-Job Training is learning on how to work with my teammates. Although I have learned a lot of technical stuffs like Software Delivery (From Automated Unit Testing to Image Builds) and a whole new field of Process Automation, I still consider learning to work harmoniously in a team environment as the most rewarding experience.

At work, there are real leaders. People like my immediate supervisor (Development Manager) and his immediate supervisor (Director of Software Development) are the *real-world* leaders. And to tell you the truth, I think that they are GREAT at what they do. In both technical-side and people-side of leading a software development team.


When I was in college, one of my biggest fear is to have an immediate supervisor that has an MBA (Business Administration) degree. I call those people “the suits”. Joel Spolsky said that “Watching non-programmers trying to run software companies is like watching someone who doesn’t know how to surf trying to surf… The cult of the MBA likes to believe that you can run organizations that do things that you don’t understand”. Which I totally agree-on… based on experience (I had this certain professor in college who have a PH.D. in BA and teaching management subjects like Quality Management who argues that the PENTAGON was infected with a virus ["the LOVE bug"] because their “firewall” was weak and not because, against the better judgment of his computer science student, of social engineering techniques).

So it was quite a relief when my supervisors at work happens to be really technical guys. Once in their careers, they were programmers. Real, actual, programmers. And that’s one of the things that motivates me at work. For me, that is what being a leader is all about. Leadership by example.

It is such a joy to come to work and see your supervisor, the development manager, DEBUGGING and TRYING to fix an issue. It is also a joy to have a manager who actually knows what you are doing. And there were instances at work while we are trying to fix a very complex issue, it is our development manager who cracked the case! I mean, there were times that our manager is much more smarter than us!

Just the other week, I saw the Director of Software Development seating at my co-worker’s workstation trying to fix an installer issue! I was shocked. A senior management guy directly working with a computer. That single event alone restored my faith on the system…

…the belief that geeky guys can still succeed in a world where business acumen is valued more than technical skills.

I’ll leave you with a short story from Joel Spolsky’s blog about Leadership as this story shares the same sentiments as mine. Enjoy!

Nowadays, when people ask me about my typical day at work, I always tell them that I’m working on a Localization Project. Most often than not, the common reply is “What’s that? Does it involve programming?” Yes, it involves “programming”, if you consider replacing a bunch of strings to their localized equivalent as “programming”.

As Mike Rowe will put it…

Localization… It’s a dirty job!

Why is it a dirty job, you ask? Consider the English phrase “Preview and Spell Check”. Now let’s see how it will translate to different languages:

French: Prévision et contrôle de charme
German: Vorbetrachtung und Rechtschreibüberprüfung
Russian: ??????????????? ???????? ? ???????? ????????????

A simple 23 letter English phrase will translate into a very complex 48 letter Russian gibberish. Do you understand now why this is a dirty job? No? Alright, let me illustrate with a simple dialog box…

Now let’s try to localize this particular dialog box into Russian…

Because some languages are just so weird, a simple phrase will translate into a paragraph! And as “programmers”, its our job to resize the offending component (See last button on the left) so that the translated phrase will fit. In this particular dialog, to be able to resize the offending button, you need to:

1. Resize the Form
2. Move the Textbox, the command button (button5) on the right , and the group box (groupbox2) on the right
   
3. Resize the groupbox (groupbox1) on the left
4. Finally, resize the offending button

You might say “Well, that’s easy! It won’t even take me 3 minutes to do that.”. Hah, I’m being too easy on you with that example. Consider this dialog then:
Haha. Still too easy? How bout this?

And it’s a bitch when the programmer that designed the original GUI does not understand the concept of GOOD UI DESIGN PRACTICES and decided that overlapping 20 groupboxes and toggling the Visible flag during runtime is a GOOD IDEA. (Yes, I know. I’ve done this a couple of times in the past and I apologize for having committed this damnable sin!)
Now, consider the fact that we have a very very huge system that contains roughly 300+ dialog boxes and the fact that we need to ship the system in 5 different languages. Don’t get me wrong, we are using a localization tool to accomplish the task but somethings just have to done MANUALLY. It’s indeed a dirty job!

This hell right here is just ONE part of the Localization Job and it’s the EASIEST PART! Since some part of our codebase is so freakin old, when you change a small part of the code, all hell breaks loose. The system will break in 15 different places at the same time! And you know what’s great? The system is already localized that you won’t understand what the error message is saying! And with a codebase consisting of MILLION LINES of code (some from the 80’s), you’ll understand why localization is a dirty job.

Here’s the upside (YES! There is an upside), Localizing a piece of software into different languages automatically converts to sales. Its good money. And at times like this, contributing to the company’s bottom line is what separates you from being laid-off to keeping your job, even though its a dirty one. )

In the future, I have 2 projects lined up that involves *real* coding. But for now, I’ll have to make do.

“It’s a dirty job but someone’s gotta do it!”

*PS: I used the term “Dialog Boxes” for the non-technical readers to understand. For the geeky guys, just translate.

Dummies can learn programming, too.

We, the nerds and the geeks, would like to believe that programming is a talent. That programming is… Something special. Something that cannot be learned fully. Something inherent — a gift from the gods. We would like to believe that programmers are born – not made.

These beliefs stems from the premise that programming is an ART. Like singing or painting.

Let me be the one to tell you that programming is NOT a talent. However, let me stress the fact that programming is an ART and as all matters concerning art, passion separates the good from the great.

Programming can be learned. Programming Languages can be learned. Algorithms can be learned. Software Engineering techniques can be learned. Everything concerning programming can be learned. So what separates great programmers from good or mediocre programmers? No, not talent. Passion.

Programming (or Software Development to be precise) is just building stuffs for people to use… It’s a modern form of craftsmanship. Even in the old times, craftsmanship is the vehicle for passion. Passionate people create great works, their magnum opus. Passion is what separates a $5 painting to a $10,000,000 dollar one. Passion is reflected in the end product… It’s as if the heart of the creator is passed on into the product.

I still believe that programmers are not born – they can be made. But hear this, Great Programmers are born. Not because great programmers are born with great intellect. Not because great programmers are born with superb logical and rational thinking skills. Not because great programmers are just geniuses…

But because GREAT programmers are born with passion. The passion to create great programs.

… and passion can never, ever be learned.

Jeepney Drivers in the Philippines

I was wrong.

For a very very long time, I’ve always thought that the reason why Software Developers leave our country and work abroad is because of pure greed.

The realization came on the day of my job offer. Don’t get me wrong, their offer was good enough. In fact, it made me think of those developers who are receiving “average” or “below average” salary.

A lot of realization came to me that day… I realized why the people of this country is so angry with the government and corrupt government officials (READ: Taxes). I also realized that even if I graduated Cum Laude in a prestigious school and even if I am working for a Global 500 company earning above average salary, I will not be able to live on my own comfortably.

On that very moment, I am living in reality… the real world — Not in the fantasy world presented on those success stories in Time Magazine about how a geek changed the world and earned a few billion dollars in the process.

So let’s talk about reality…

In the Philippines, an average entry level software developer earns about 15,000 – 25,000 PHP a month (Gross). For the sake of our example, let’s say that Peter (an entry level software developer) earns about 20,000 PHP per month. If you factor-in all the deductables (30% tax, SSS, etc), Peter will have a take home pay of 15,308.34 PHP (Click here for the calculator).

On the other end of the spectrum, Pedro, a very humble Jeepney Driver touring the Guadalupe route in Makati who never need to pay his taxes earns about a reasonable 500 pesos per day. Since Pedro here is very hardworking, he works 7 days a week. So Pedro earns about 15,000 php per month!

So that leads us to my conclusion that a Software Developer who finished a college degree and working on a multinational company is equivalent to 2 Jeepney Drivers who just have a high school diploma and is working without a boss and without the need to kiss the boss’ ass on a daily basis!

With those things in mind, I think that in the near future, I will be included in the roster of Gen Y OFWs. Things really didn’t change that much since Rizal’s time, we are still under foreign rule… but that’s another blog post.
Here’s the recent Salary Report for IT Professionals here in the Philippines. Enjoy!