Recently I was reviewing some code written by a new programmer, this person had demonstrated good knowledge of his domain and was quite well regarded by everyone. However when I looked at his code I saw a familiar pattern that I had seen before which I like to call the “Enlightened Newbie Syndrome” (ENS).

You can detect ENS when you see code that is a mish-mash of good code intermingled with overkill on “best practices”. The Enlightened Newbie will focus on making sure that his code adheres to the latest naming conventions, follows TDD but doesn’t test the right things and applies design patterns too liberally

In this particular case the programmer had used different naming conventions for variables based on it’s usage, so for e.g. pascal case for params, all caps with underscroes for local variables etc. Another classic sympton was the elaborate comments about assignment statements complete with box decorations around the comment. Further the variables if named properly would have been enough to indicate their usage but instead the variable names were extremely generic and then had big comment boxes near them to describe what the variable was used for.

The saving grace of the code was that logically it was setup correctly, but it was clear that the programmer had not unit tested his code at all, my first invocation of the code gave me wrong results and upon further analysis it looked like a lot of the edge cases had been missed out.

I remember being an enlightened newbie once, I had read all the books on design patterns, refactoring, TDD etc. but had not yet written a lot of code. So when I worked on my real project it was very tough for me to find the style that worked for me and I ended up with a bit of everything at the start. However as I worked on that code for the next 3 years all the things that I had read started to make sense and I realized that the essence is to not follow a practice religiously but to make use of good judgement to see what applies where.

So in my mind there is only one cure for ENS and that is to just write a lot of software in a team environment. Note that I am not talking about just chruning out code but actual working software, and again not in isolation but in a team. Because

1. You can write a lot of code and only improve your typing and not learn a lot about programming, however when you build an actual product/service and then have users or other systems interacting with it, you get a lot of feedback on what works and what does not. Based on the feedback and other external requirements the software usually goes through a lot of changes and when you have to go back into your code and make changes then you really appreciate brevity, simplicty and the DRY principle.

2. Working in a team environment exposes you to code that is both better and worse than you, it gives you more exposure to the different ways something can be done and all the different ways you can use tools to make your work easier. Teams are just fantastic platforms for improving your skill, knowledge and productivity.

Just saw Hacking Democracy on HBO, it’s available online as well. I can’t believe the whole electronic voting system is built on Access and a VB frontend!!

A few years ago before the whole weblogs revolution kicked off my daily hangout was “The Lounge” at codeproject.com, it was fun to participate in discussions with peers on a wide variety of topics. When I initially started my blog I thought that I could kick off a discussion by posting a blog and then having people respond to it so that I could track all my discussions via this site. In hindsight this seems like such a bad idea but the weblog thing was still in it’s infancy at that time. Currently I just use the weblog to “log” interesting things I find and my thoughts and opinions rather than as a discussion network. But I miss the discussion part, seeing the opinions of different people with different perspectives is something I’ve always enjoyed, so maybe there is a way to combine the best of both worlds? Maybe a blog platform that centralizes your comments/discussions?

A decade ago when I was still in high school I remember our economics teacher going over the economic issues plaguing India, at the top of the list was “population”, it seemed like all economic problems of India stemmed from it’s high population count and that lowering the population would in turn result in a solution to the economic issues.

Yesterday I was listening to a nerd TV podcast with Bill Joy and he was talking about how the distribution of smart people is uniform and if India and China has that many more people then statistically the distribution of smart people in those countries would be higher as well. This got me thinking about how the perception of India has changes because of the IT boom that has happened in India, today everyone talks about how the populations of India and China give them an edge over all other countries in terms of manpower available for both manufacturing as well as services.

In the early 1990s when India was a closed economy, it was not apparent how India’s population could be leveraged as an advantage, but with the opening of the economy to foreign investments and more importantly I feel with the Internet making global communication ubiquitous all of a sudden India was at the center of the IT revolution, earning and growing like crazy. Of course it’ll take a long time for the wealth to trickle down to the masses but once the money is there and consumerist culture is in place the distribution of wealth happens naturally.

I would love to talk to my teacher some time and see if they still teach the same theory in school now

For the past few days I’ve been investigating some memory leak issues in our desktop application. The problem started showing up when we saw that opening new documents and then closing them didn’t have any negative impact on the memory usage. Initial tests using vadump and process explorer confirmed that there was an issue and so we the developers started looking into it.

Initially it looked like the problem was that certain event handlers were causing references to closed documents to hang on a couple of ones that I remember are Application.Idle and SystemEvents.PowerModeChanged. Next there were some references via event handlers that were being held by Singleton objects and some service objects and those were easily handled as well.

After this we could see that the references were still hanging around, btw we were using a combination of ANTS profiler, WinDBG (dumpheap + gcroot) and the VS.Net debugger all this while to investigate the issue. After fixing the obvious issues we struggled to find the root cause of the memory leaks. Then I looked around for alternate profilers and came across .Net Memory Profiler from SciTec, using this gave a much clearer picture into the issue, you see the new profiler gave you allocation stacks for all references and the ability to reflect over the instance fields, using this I started seeing that two third-party components that we were using were causing the issue.

Basically both third-party components, one a very well known UI toolkit and another one that provides skinning support to controls were storing references to controls in static hashtables. In one toolkit a bug in the code caused the reference from the hashtable to remain even after it was not required and in the second case I think those guys just didn’t know how to remove an entry from a hashtable, they were simply setting the value of the key to be null causing a reference to the key to be held by the static hashtable.

We now need to hack around these issues either by using Reflection or getting an updated build from the vendors.

Some of the lessons I’ve learnt from this

• Always, Always have source code for any third-party component that you are using in your application. For any non-trivial usage you’ll always end up fixing bugs in the component.
• When putting any data in static fields, double check to make sure that it’s really required and keep in mind the memory impact of the decision also provide a clean API to clean up the static data.
• If your’re hooking onto an event then make sure to unhook when it’s no longer required.

Last week all of us were baffled when suddenly one part of our application that uploads files to a FTP server stopped working. The strange thing was that the same build has been working without any issues for the past one week. We looked at everything that could have gone wrong, server, configuration, code but everything was setup fine and hadn’t been changed. Also interestingly it stopped working for everyone except the developer who was responsible for the feature.

The first thing we did was to enable detailed logging to see what was happening, the logs showed two problems

1. We were incorrectly formatting the path of file to upload
2. The .Net framework code was changing folders after login to the root folder of the ftp where it didn’t have permissions to upload the file

Further investigation showed that the second issue was not coming on the developer’s machine. Most puzzling indeed.

Then I remembered that last week .Net had issued a critical hotfix for .Net 2.0, could this be the issue. We verified that the developer didn’t have the hotfix and all machines which were failing did have, Strike 1! Next we uninstalled the hotfix from one of the machines and the FTP uploads started working, Strike 2!! Finally we fixed the incorrect formatting of the ftp url and the issue got resolved on all machines with or without the hotfix, Strike 3! Issue resolved!

The problem was that the hotfix changed the implementation of the FTP code inside the .Net framework so that it behaved differently when passed an incorrectly formatted url.

This was the first time I saw a working app fail because of the way an incorrect argument was handled by a newer version of the framework. It was a good learning experience though Also this strengthens my belief in asserting all assumptions in code because if we had asserted that the url was infact of the format that we were expecting, this issue would never have happened in the first place.