Sankofa » Job

On the High Turnover Rate of Software Developers or How to Retain your Best Software Developers and Programmers

Ian Uy — Sun, 26 Sep 2010 11:10:40 +0000

It is not exactly news that programmers love to quit their job. It is an industry-wide obsession. The annual turnover rate for the High-Tech industry in 2008 is a little bit above 20% (2 out of 10 employees quit every year). A typical programmer on a typical software company stays for about 23 months on average. For an employer, these figures are scary – especially if you employ skilled workers such as programmers and software developers. High turnover rates of skilled professionals can pose as a risk to the business or organization, due to the human capital (such as skills, training, and knowledge) lost.

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.

Share and Enjoy:

High Salary is Killing the Software Industry

Ian Uy — Sun, 13 Sep 2009 16:20:10 +0000

Judy Ann Santos - Philippine Superstar

If there is someone that I hate more than Ms. Judy Ann Santos, that someone would have to be a person who has a job that he or she is not passionate about.

I don’t know if it’s the Philippine economy or just the Filipino culture that makes it “okay” for someone to live a life of suffering; enduring a job he or she hates for exchange of a comfortable life and a prestigious career. I’ve heard countless stories of teenagers being forced by their parents to take a course like Medicine, Law or Engineering (Courses which will attach fancy-sounding, age-old, titles to their child’s name) against their child’s will. I’ve accidentally watched countless Pinoy movies with the same theme. (Kid wants to major in Fine Arts, MOM aka Mrs. Attorney wants the kid to major in Law and be a lawyer. Sounds familiar?)

Five years ago, Nursing became a popular course for High School graduates to take in college. I know that because that was the year when I graduated from High School. During that time, some of my classmates took Nursing courses not because they want to be nurses but just because being a nurse would almost guarantee a free-work pass to the US and a chance of snatching that American dream. And you know what? I think majority of the newly graduated nurses thinks the same too.

Nursing school in the Philippines

Is this already a deeply-ingrained practice in our society? Seems so.

In College, I have met a lot of people who did not know the exact reason why they took Computer Science. Most of them did not even know what Computer Science is when they took it. Some of them took the course because they heard from their Uncle’s Friend’s Cousin’s who is the Executive Vice President of a multinational company that being a programmer pays well. True Story. Some of them took computer science because they thought computer science is EASY and because they thought computer-related jobs are easy to get.

For me, the only reason that you should take a course is because you absolutely love it. No other reason should override that. Your course will more-or-less dictate your life long profession. It will define you. You will breathe it, you will think about it, most of your waking hours will be used to deal with it. IT WILL DEFINE YOU. Why waste it in something you don’t really want? That’s stupid.

This pattern is not limited to Nursing or Computer Science. Look around you… Technical support staff, Call center agents, etc. I bet you that majority of them are there not because they love their job but because of the money. And you wonder why you are getting crappy customer service when you call your DSL support hotline? The moment they pickup the phone, they are already thinking of the best and fastest way to put it down. The more calls they get, the more money they’ll receive. This should stop. (One could argue that the system is to be blamed, but who can change the system?)

When I was in college, I really believed that everyone working in the software industry are passionate, nerdy, geeky programmers. But reality begs to disagree. I have met my share of software developers who are just here for the money, for the career.

So what is wrong with having a job that you are not passionate about? Well, I believe that if one is not passionate about his or her job one will always produce average and mediocre result. The Filipino culture of “Puwede na yan” (That’s good enough) fits the image perfectly. Maybe this is why you can see this pattern everywhere?

If you don’t really like what you are doing and if you are only after the rewards of finishing the job, you would never go the extra mile to rise above mediocrity. Well, if there is an additional reward for doing so, then you just might. But you would never work unpaid on an overtime just because you want to add that last “touch” that will make your result or product a little more perfect, because there is no additional reward for doing so.

I really admire the Japanese work ethics… they always aim to perfect something. I call that the Samurai Mindset, the art of the samurai. On the other hand, the unpassionate Filipino worker would outright claim that “nothing is perfect”, “perfection is impossible” then give up trying.

During my college days, I’ve met my fair share of these unpassionate programmers. Some of them are even dean’s listers and cumlaudes. Its just sad. You can see it on their projects (Computer Systems)… Since projects only accounts for 15% of the total grade, they would submit these mediocre systems that just meet the requirements. They would argue that its pointless to make your project perfect since its only a portion of the grade. Never trust the grades.

It is a well known fact that the local IT industry gives one of the highest salary and that is making the situation a lot worse. Just like in Nursing, teenagers and their parents are most likely to choose IT courses because of the eventual monetary payoff and that is attracting more potential unpassionate programmers.

And Software companies hiring non-technical graduates for a programming job isn’t helping either.

Without passionate programmers, the local Software Industry would never be able to produce really innovative products. We will just be stuck as a source for cheap software “labor”. Making and remaking the same boring “business” systems. Producing average products, for average people.

Share and Enjoy:

Work is now officially “WORK”

Ian Uy — Sun, 21 Jun 2009 15:25:18 +0000

I can still clearly remember the words of our Tech Lead as if it was just said yesterday…

“Madali lang to sayo. Parang laro laro lang.”

He would always give me that answer while putting on a big, warm smile. Every time that I see him coding or preparing a design document, I would always approach him and ask him out of curiosity, “Ano ginagawa mo Sir? Mahirap ba yan?” and he would always give me that answer. And I have always wondered what he meant by “parang laro laro lang“. Sadly, I was never able to ask him about the actual meaning of it (he is now in Singapore) but as an Intern, I assumed that he meant that “If you’re having fun, it’s easy!“.

So much for work being fun?

Even from Day 1, I have never looked at my job as *real* work. I have always looked at it as “laro laro lang”. That work is something fun. That does not mean that I don’t take my job seriously. As a matter of fact, I think that I am doing a good job while having tons of fun. Of course, seeing your job as “laro laro lang” does have some negative effects. As one of my co-worker has pointed out, I’m a bit lacking in the “professionalism” department. I don’t exactly know how she arrived to that fact but I am assuming that she doesn’t like me watching SNSD videos in the office or playing a casual Facebook game once in a while.

So I wondered, what’s the big fuss about Professionalism and what exactly is professionalism? A close colleague of mine suggested that I should read about professionalism while we are having a discussion about proper work ethics. And so I did. Quoting from Wikipedia, for someone to be considered as a “professional”, he/she should have the following:

Academic qualifications – a doctoral or law degree – i.e., university college/institute

Expert and specialised knowledge in field which one is practising professionally

Excellent manual/practical and literary skills in relation to profession

High quality work in (examples): creations, products, services, presentations, consultancy, primary/other research, administrative, marketing or other work endeavours.

A high standard of professional ethics, behaviour and work activities while carrying out one’s profession (as an employee, self-employed person, career, enterprise, business, company, or partnership/associate/colleague, etc.

Reasonable work moral and motivation. Having interest and desire to do a job well as well as holding positive attitude towards the profession are important elements in attaining a high level of professionalism.

1, check. 2, specialized knowledge, check. 3, sure, check. 4, check. 6, motivation! check!. Out of the 6 criteria, I sort-of fail in one so I’m about 83.33% Professional. Kidding aside, despite having someone put me on the “unprofessional” basket, I still believe that I am a professional. I still think that I have a high standard of professional ethics (ask the people that I have work with), and I still think that my behavior, even though you can classify me as a Kid with ADHD, is still within the “appropriate” range (I am not a model employee in terms of behavior, though). I admit that some of my work activities are not professional though, like playing a casual Facebook game in the office. BUT I assure you, it hasn’t negatively affected my output and my job. I would even go out on the limb here and claim that being able to have fun at work resulted in a positive output. (Facebook vs. Productivity articles here and here)

"Nerds are always getting in trouble. They say improper things for the same reason they dress unfashionably and have good ideas. Convention has less hold over them." - Paul Graham (Hackers and Painters)

Last Friday could have been one of the happiest day of my young career (~4 months). I was recognized for my efforts in delivering a product on time that is of high-quality (I’m paraphrasing here, couldn’t remember the exact words from the certificate). But sadly, last Friday turned out to be one of the saddest day in my professional life.

During our weekly team meeting (which is held every Friday), our Manager gave a guideline about the team’s “Expectations on proper usage of internet resource”. The guideline basically says:

Use the internet resource wisely
Access to Social Networking Sites like Friendster, Facebook and Multiply should not be abused
If you’re going to use the internet that is non-work related, be discreet.
Absolutely, no GAMES allowed

The guys made it clear that this is just a guideline, not a set of rules that we need to follow. They also stressed the fact that access to Social Network Sites are not forbidden but we should exercise our “best judgment” when accessing them during office hours. Finally, it was said, in verbatim, that games of any sort are no longer allowed.

In actuality, I am not against this guideline. The exact instance that I took the job, I was asked to sign a 13-page document that basically say “The internet is just for work”. I am just frustrated that the guidelines are not clear. Telling me to use my “best judgment” is like giving a kid the key to a candy store. My judgment and reasoning is so unconventional that conflict may arise from my actions. Also, judgment is subjective, what’s okay for me may not be okay for others and what’s okay for them may not be okay for me and that scares the sh*t out of me.

For some, this guideline is just, well, a guideline. “This is just a guideline, don’t take it too seriously”, a close colleague told me. Well, not for me. This particular guideline is a team “expectation”. It is like a promise that we have to each other. That is how I feel about it.

Personally, using my best judgment, I think that I have never abused my usage of the Internet. I may not be discreet on using them because I don’t understand the value of being discreet. I mean, we are still doing it, but we are doing it “secretly”. For me, Its like lying and I don’t like to lie.

I don’t understand why casual games in Facebook should be banned. I don’t understand the difference between a video and a game. If we are talking about bandwidth, the bandwidth consumption of a 5 minute video in Youtube is so much greater than the bandwidth consumed by Barn Buddy, a casual game that I am playing in Facebook.One of my colleague has pointed out that you are not just focused on the game but your cursor is also in it (You can’t really multi-task!). That’s a good point though but I’m not entirely convinced. But for the sake of following the guidelines and as a respect to the people around me, I will indefinitely suspend playing games while in the office (or I will be just “discreet” ).

Judgment is subjective. And that scares the s*it out of me.

To check how different the judgment of my colleagues are, I asked them personally about their take on the guideline. And boy I was not that surprised to discover that judgement is really subjective. One of the guys basically told me that “The 8 hours in the office should just be for pure work”, while another guy told me that “It’s okay to take a break once in a while to relieve stress”. Another guy told me that “This is not an issue about productivity but the proper usage of the company resources.”.

This is what I am really scared about, judgment is subjective. You see, if I exercise my “best judgment” and still use Facebook, people on the team may think that I am being “abusive”, they may think that I am not paying attention to the guidelines, that I am disrespecting the entire team by not doing my part.

To be on the safe side, I just stopped using the Internet for non-work related stuff for the rest of the day. Considering that I only stopped using the Internet for just 4 hours, the psychological effect is so devastating. My motivation was down to ZERO and it felt like that I am just a slave that should do what he is supposed to do. From that point on, I felt that work is no longer fun. Work is now officially work and that made me extremely frustrated and sad.

My biggest fear is that this guideline will make work no longer fun. It will make work feel like *real* work. I can tolerate that kind of environment but I am afraid that this will hinder great work. I have always believed that the source of my skills is my passion. That I am doing a great job because I am enjoying every single moment of it. I am afraid that my output will be negatively affected if I no longer find work enjoyable. To quote Joel Spolsky:

For his part, Jeff says he didn’t want our new venture to feel “like work” — that if Stack Overflow wasn’t fun to do, he didn’t want to be doing it. If I had tried to make him play by my rules, I don’t think the project would have come together, at least not as well as it has.

The truth is, the three guys who coded Stack Overflow are great programmers. They’re smart, and they get things done. And in the end, that’s what really matters.

I believe that my team is composed of great software developers. I believe that we are smart and we can get things done. And I also believe that this is what really matter, to get things done.

So by Monday, I will default back to doing what I have always done which is to have fun. I will still try my best to get things done (which I have always done in the past). I will no longer play casual games in the office (to show my respect to the team’s expecatation) or at least hide somewhere when doing it . I can’t promise to be discreet but rest assured that my work and my job is still my priority. Finally, I believe in my teammates… I believe that they would always be there to offer me their best judgment when they find mine unfitting.

Share and Enjoy:

ASP.NET 1.X to ASP.NET 2.0 Migration Postback Problem

Ian Uy — Sun, 17 May 2009 15:40:17 +0000

ASP.NET Migration Problem

If you’ve read my previous blog post, I talked about some of the problems encountered while migrating some of our web applications from .NET 1.1 to .NET 2.0. Well, those products are now handed off to the Test Department for their routine torture.

Just a couple of days after the hand-off (Hand-off to Test or HOTT), the tester who is testing the product filed two (2) Tracks (Incident/Bug/Problem). Since I am the only developer working on the product, all of the tracks will automatically be assigned to me. The said tracks that were filed have the same “type” of problem.

When browsing for a file (Backup File / File Upload), the value of the Textbox would change back to its default value when the page re-loads.

The web application that I am supporting was originally written in .NET 1.1 using Visual Studio 2003. To migrate it to .NET 2.0, we converted the solutions to VS2005. Aside from some minor problems like RESX incompatibility and broken Calendar Controls, the Web Application worked — I thought it did.

We have a Backup Restoration Page to allow the user to restore the web application in-case of Armageddon-like circumstances. The said page basically contain 3 components:

A Read-Only Textbox that holds the path of the Backup File . This Textbox has a default value of C:\Backups\Backup.bak
A Browse button that will launch a custom page that will allow the user to browse for the Backup File. The value selected there will be posted-back to the Backup Restoration Page.
A “Restore” button to start the restoration process.

When I tried to repro (reproduce) the bug on my Virtual Machine setup, I was able to verify that the path of the Backup File is losing its value on postback. To put it more precisely, the Textbox is not retaining the correct path since it is changing back to its default value on postback.

After hours of debugging, I was no where close in determining the cause of the problem. So I did a quick search on Google and found out that this is a common problem during migration from ASP.NET 1.1 to ASP.NET 2.0.

The problem is that Microsoft changed the behavior of read-only textboxes on ASP.NET 2.0.

ASP.NET 2.0 had a design change by which a control if marked with its ReadOnly property as true, would ignore client side changes and would lose the same across postback. So if you tried modifying the text box value or add a value to the text box using Javascript you wouldnt be able to retireve the value in the code behind or simply the value will be lost across postback.

This behaviour is by design in ASP.NET 2.0 and it has been designed with the idea that a ReadOnly TextBox shouldnt be modified in the client side by a malicious code.

Microsoft has a point. What’s the point of using a Textbox if you’re going to set it to Read-Only? Why not use a Label instead?

Fortunately, we have three simple workarounds for this problem.

Use a Label instead of a Read-Only Textbox. (Heard of Borders?)
Set the Read-Only property of the Textbox to FALSE (If you don’t really need the Read-Only Property)
But if you are really insisting of using a Read-Only Textbox, then we need to “fool” ASP.NET that the Textbox is not Read-Only even if it is.

To “fool” ASP.NET, you need to set the Read-Only property of the Textbox to FALSE during design time (Using the Property Pane) then set it to Read-Only on Page Load during runtime. You CANNOT use Textbox1.ReadOnly = true. You need to set the read-only attribute using the Attribute.Add() method.

// This is part of the C# code-behind file.
protected void Page_Load(object sender, EventArgs e)
{
     TextBox1.Attributes.Add("readonly", "readonly");
}

That will solve your postback problems.

References:

Share and Enjoy:

Migration: Why Developers Hate Microsoft or Why Developers Hate Vista or My First Encounter how Microsoft can Break your Software

Ian Uy — Sun, 10 May 2009 14:13:29 +0000

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 parameters of each .NET 1.1 strings to match the .NET 2.0 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, "

 
");

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:


.....






<

May 2009
>





Sun
Mon
Tue
Wed
Thu
Fri
Sat


26
27
28
29
30

1
2

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


.....






<

May 2009
>





Sun
Mon
Tue
Wed
Thu
Fri
Sat


26
27
28
29
30
1
2

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 (