Wednesday, July 30, 2008

Too Slow or Too Fast

I had a conversation with a co-worker recently that got me thinking. He had been at a local .Net users' group, and had mentioned that we hadn't upgraded to .Net 3.5 yet. Everyone else was amazed that we weren't taking advantage of this yet.

As I read various blogs, I see lots of companies working on the cutting edge, using things like .Net 3.5, LINQ, the new MVC framework, etc. Sometimes I wonder how they are able to justify moving to these new technologies so quickly. I'm very much in favor of learning new things, and using them where it makes sense, but I think it is also wise to sometimes wait a bit before rushing to upgrade.

We have a product (actually several products, but we consider them one system) with around a million lines of C# code. It currently supports around 400 internal users, as well as 50,000 external users. Our main focus has to be to keep it running, while adding new features and fixing bugs as needed. Without being able to show a tangible benefit of upgrading, we would have a difficult time telling the business that we needed several weeks to convert this system to the latest and greatest offering.

When we made the move to .Net 2.0, we were able to sell them on the fact that it gave us a new web deployment model that would allow us to react to their demands more quickly, as well as the possibility of moving to 64-bit code eventually. At the start of this year, I was given tentative approval to upgrade to .Net 3.5, but since then, we've been so busy that I haven't had a chance. At this point, I'm not sure I would be able to convince anyone that it was worth our time and effort.

Maybe some of the other companies I see adopting the latest thing do so with smaller applications, or with totally new products. Unfortunately, we don't often have the opportunity to do that, since my group's main focus is the large system I mentioned earlier. It does disappoint me somewhat, since I would love to be learning the new technologies, in case I need to find a new job.

Still, it has made me wonder if we are the ones moving too slowly or everyone else is moving too quickly. I know I really don't want to be the one debugging Microsoft's latest code. I've been involved in that before with other products, and it was no fun. We had a product that was delayed over a year while we worked with a vendor to squash all the memory leaks in their DLL.

So, the way I see it, we can either stay with what works until we see a pressing reason to upgrade, or jump in with both feet and deal with the consequences. One is good for business, the other one may be better for my career options.

No comments: