A Surprise Project

As I was preparing to join an ASP.NET project this week, there came a chance to do another little project. It is about monitoring and sending commands to an embedded device through a serial port. I estimated the work hours and if we reach an agreement with the client, I will start coding next week. The cool thing is that I will get some experience with .NET 2.0, since it introduces a new class System.IO.Ports.SerialPort (which hopefully is going to make the task pretty trivial).

In my preparation for the job I searched what's new or changed in .NET 2.0. I don't want unpleasant surprises and I like to try some new things like generics, anonymous delegates etc. I found a great summary here and you might also check all free excerpts of Patrick Smacchia's book Practical .NET2 and C#2. A great resource on the .NET class SerialPort is this Noah Coad's post. In the meantime I got acquainted with some serial port theory and tried a few useful tools to monitor, sniff or emulate serial port communication. I found a cool tool that creates a virtual COM port and forwards all its communication to TCP port, so I wrote a simple TCP server to log the data received at the virtual port and I will also write a simple TCP client to send data.

Another interesting thing I tried today was an alternative .NET 2.0 enabled IDE. VS.NET 2005 has its problems and one of them is that it is slow. Unfortunately the machine, I am working currently on, can't tolerate much CPU and memory pressure. I searched for a more lightweight IDE and stumbled upon X-develop, which looks superb. It is feature-rich (actually in a few ways it's better than VS.NET, even when powered by ReSharper) and it seems a little less CPU and memory hungry. I can evaluate it for free for 20 days, which is enough for the task, but I might stick to VS.NET 2005.

The estimating part is what bothered me a bit. I had a chance to test my skills in this area a few monts ago and it didn't work out very well. I had a list of another developer's estimates that seemed too conservative to me. I thought that I could implement the features twice or thrice faster, but at the end the other's guy estimates were more closer to reality. But since it was not a greenfield development and the code was not easily maintainable, probably that's why it took so long.

Now I am starting from scratch, I have a good idea what is to be done and all the implementation details are pretty clear. Let's see if I get it right this time. The not so obvious time-consuming activities that I tried not to ignore included: communication, writing testing and logging code, takling unpredicted problems, etc. Some people recommend that you multiply your estimated coding time by three and you are likely to come close to reality. But it depends on the project scope and the people involved. In my case I should multiply probably just by two, since I will do it solo and it looks pretty straightforward.