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.

Working From Home

A few months ago, my company made the decision to allow people in the IT department to choose to work from home at least a few days each week. This was partly to help with rising gas prices, and partly to help retain employees, since we've had a hard time filling vacancies recently. I gladly took them up on this, even though I only live about 4 miles from work.

In the time I've been telecommuting, I've learned a few things about how to make it work, at least for me.

• Have somewhere private. If you have a spouse and/or kids at home, you must have someplace you can go to be totally isolated from them. Having them interrupt you just doesn't work. I'm lucky in that we just finished our basement, and I have a nice office to work from.
• Have a comfortable chair and a good desk. Before I got my new office, both my chair and my desk were over 10 years old, and would not have made a good environment to to real work in. They were fine for casual use, but not 8 hours a day. I bough an all new desk and chair, and have been happy with that ever since.
• Have the right equipment. I already had a company-supplied laptop, and I supplement it at home by plugging in a keyboard and mouse, and attaching to my personal monitor, so I can have dual screens. I've had dual screens at work for several years now, and I don't think I could live without it anymore, so that was a must for me. (Some people may be lucky and have their company buy these, but part of the conditions for this was that no extra equipment, beyond a USB headset, would be purchased).
  
• Treat going to work just like you would on a normal day where you actually leave home. I still get up at my normal time, shower, get dressed, have breakfast, etc. Then, when 8:00 comes around, I say goodbye to my wife and kids and retreat into my office. I do come out occasionally for breaks, and for lunch, but I try to keep that to a minimum. I know for some people, the attraction of telecommuting is that they can dress like a slob or not shower, but for me, that is part of getting into the right mindset to go to work.
• Keep track of what you do each day. My manager requires a quick email at the end of the day listing what we accomplished that day. I think that's a good idea, because it keeps me focused on getting as much done as I can so I can show that I've been productive, even though nobody can see me.
• Keep in touch with your co-workers. We have IP phones and a corporate instant message program in addition to email that helps us all communicate even when nobody's in the office. This is key, since you can't just holler over the cube wall when you need to talk to someone.

Telecommuting has worked out great for me. There are usually fewer distractions, and when I have something intense to work on, I can really focus and get it done. It isn't for everyone; some people may miss the daily interaction with co-workers. But if you can handle it, it can be a real productivity booster. I'm really grateful that my company has allowed us to do this.

Basics: No Warnings

Does your code compile with no warnings? Most developers wouldn't dream of checking in code that didn't compiler without errors, but what about warnings? At other companies I've worked at, the code has been full of warning messages. Some of them were relatively harmless (I was working in legacy C code at the time, and as the compiler go better, more warnings were shown). Others were more critical, and really should have been addressed.

In my current job, the main product I work on has around 1 million lines of code, and I'm proud to say that we keep it warning-free. This is no small feat, since we use XML comments, and have the option turned on that generates a warning whenever one is missing from a public or protected member.

Some people would argue that a warning is just that: a warning. If it isn't an error, why bother fixing it? For one, it clutters up the output window and the error list in Visual Studio. It's no fun having to page through several dozen warnings just to find the error(s) you're looking for.

The most important reason, though, is that often, those warnings may be pointing to something more critical that could be wrong with your code. For example, every time we've upgraded the Infragistics library we use, we've had a number of warnings appear because they are planning on deprecating some methods or properties in a future build, and have marked them as such in the current build. Sure, the code still compiles and runs, but maybe it won't in the next build. Infragistics is giving us advance warning that our code may break. We always make it a point to fix those as part of the upgrade process.

Another warning that I've seen a few times is when a developer declares a method in a class with the same signature as one in the base class without realizing it. The compiler warns that you have hidden the base method, and you should either rename it or use the "new" keyword. If you don't clear up this warning, you may be breaking something without even realizing it.

The next time you build the product you're working on, take a look at the build results. If you're getting warning messages, figure out why and get rid of them.

Code Branching and Merging

At work, we've recently started using multiple branches in our configuration management tool. We've had to do this to accommodate simultaneous development on two different major initiatives (one if which is currently in test and one in the early stages of development) along with maintenance releases that the business can't wait for anymore.

In the past, we've had a more simple branching model, where we do a major release off the trunk, and then create a branch for the inevitable "point releases" that we would do to fix things found in the first build. This allowed us to continue development on other projects while only releasing bug fixes in the point builds.

This has been quite a learning process for our small team. I'm actually glad our team is so small; otherwise I'm not sure this would work at all. Over the last week, we've been working on the branch that is already in production, while the QA group tests the most recent major build, which is one higher than the branch in production. As we've done that, we've had to check in our changes (once they test out), then merge them to two other branches, and test those. Finally, today, we did the build on that branch. At this point, we merged our changes from the past week into the trunk. In theory, everything should be relatively in sync, except for new development on the major initiative branch.

To get to the point of this post, here are a few things I've learned since we started doing this:

• Communication is key. At first, some team members were confused over which branches to check their changes into. Luckily, this was quickly resolved with a couple of email exchanges.
• Merging can be hard. One of our developers is not as familiar with branching and merging as the others. This developer initially just copied the changed files into the other branches, rather than using the merge tool. This led to code that didn't even build, let alone run correctly. Once it was explained how merging was supposed to work, this was resolved.
• A good merge tool is required. In an earlier post I recommended WinMerge. That tool has made merging far less painful than what it might have been. Trying to merge files by hand or even using the tool provided with StarTeam is not something I would like to have to do.
• Even a simple change is no longer simple. With this new model, we have to test our changes in the branch we're working in, sometimes for all the countries we support (we currently do business in 7 countries, with 4 different languages). Then, we have to merge the code to each branch and repeat those tests. This means even a one or two line change can easily eat up 2-3 hours of time.
• Code separation can really save the day. During this iteration of changes, we were lucky that we had no merge conflicts. Part of this is due to the fact that our system is fairly large, so there are a lot of files. It also helps that we have the system architected in layers, so the business logic is separate from the presentation logic and the data access layer. That made it far less likely that two developers would be in the same section of code at the same time.

Branching and merging are difficult at times, but they eventually come up in any organization that releases software, even if it is only to internal users. The best thing to do is come up with a plan, document it, and then stick with it, at least as long as it makes sense. You should, of course, revisit it from time to time and make sure it is still working for you, and make adjustments if it isn't.

Firefox Extensions for Web Development

In my last post, I listed a number of tools I use daily to help me develop software. In this post, I'm going to cover some essential Firefox extensions for doing web development. Firefox is a great browser out of the box, but adding a few extensions (or "Add-ons" as they've started calling them) can make it even better. There are extensions for just about any purpose you can imagine, but I'm going to focus on the ones that help developing and debugging web applications.

• Web Developer. The name pretty much says it all. This add-on sits adds a new toolbar, with a ton of useful options, from outlining page elements, to viewing source in different ways, to viewing cookie information. Viewing cookies is something I've used quite a bit. When you select that option, it shows you a list of every cookie that was posted to the selected page, including their values, path and expiration. This is invaluable when trouble-shooting cookie-related issues.
• Firebug. Firebug is similar to the Web Developer add-on, but it adds even more functionality. It's like having a debugger built in to your browser. You can edit, debug and monitor CSS, HTML and Javascript live in any web page.
• JSView. This add-on lets you view external Javascript and CSS files easily. It adds an option on the right-click menu, and also in the status bar that lists all external Javascript and CSS files loaded by the current page. Selecting one brings it up either in the standard Firefox source viewer, or in an external application of your choice. This is great for checking out how somone else's page is put together.
• IE Tab. As much as I love Firefox, I still have to make my apps compatible with IE. Rather than loading a separate instance, IE Tab lets me view my page in IE on a tab within Firefox. You can also configure it to automatically load specific sites in an IE tab instance, which can be useful for sites like MSDN or Hotmail, which function better in IE than in Firefox.
• YSlow. From the description on the linked page: "YSlow analyzes web pages and tells you why they're slow based on Yahoo's rules for high performance web sites." This one requires Firebug to be installed. It gives you a list of things to check for to make your pages load faster.

These are the development add-ons that I'm currently using. I'm sure I'll add more over time, but just adding these few has made Firefox an excellent web development tool.

Indispensible Tools

Every developer eventually builds up a set of tools that they can't imagine doing development without. These can be anything from preferred text editors to specialty debugging tools. I have a few that I've come to rely on over the years, and I'm going to list them here.

• Metapad. This is a very lightweight Notepad replacement, that has a few extra features. I like it because it loads fast and doesn't take much memory, but it still does more than the standard Windows Notepad. It hasn't been updated for awhile, but it still works well for what I need it for. There are other Notepad replacements out there, so if you don't like Metapad, you can choose one of them.
• CLCL. This is a clipboard extender. It lets me keep the last 30 items I copied to the clipboard available for use again. How many times have you copied something with the intention of pasting it into another file, and then accidentally hit Ctrl-C before you can make it to your destination, losing what you were going to paste? With CLCL installed, you don't have to worry, because it will still be available.
• WinKey. I'm a big keyboard user, and this app allows me to start frequently used applications with a single keystroke. It lets you assign extra Windows Key shortcuts. Windows has several built in, like Win-E for Explorer or Win-R for Run command, but with WinKey installed, you can assign your own. I usually assign keys for starting my browser, Metapad, Paint.NET, and other things I use a lot.
• SQL Prompt. If you do much SQL Server coding at all, this tool is a real timesaver. It is basically Intellisense for SQL Server Management Studio. In addition to knowing all the SQL syntax, it also discovers your database schema, and can autocomplete table and column names as you type. It can also auto-format your SQL as you type, and has a ton of preferences for setting up your preferred style. It isn't free, or even cheap, but it is well worth the money in my opinion.
• Paint.NET. I don't do a lot of image manipulation, so Photoshop would be overkill for me. Paint.NET is a free image editor, written in C#, and it has evolved over time from a basic image editor to a very powerful one, including layers, unlimited undo, and a lot of special effects. If you don't need the power of Photoshop, Paint.NET is highly recommended.
• Cygwin. As I said above, I'm a big keyboard user, and this extends to using the command prompt a lot as well. I got my professional start programming in a Unix environment, and really got spoiled by the rich command-line environment provided by Unix. Cygwin brings much of this to Windows. I used several of the included tools to create the build server we use at work.
• WinMerge. We use StarTeam for our configuration management tool at work, and while it does what it needs to do well, I wasn't impressed with the diff/merge utility that comes bundled with it. Instead I use WinMerge, which is much more intuitive, and which integrates well with StarTeam. Here is a post on integrating WinMerge with StarTeam.
• KeyTweak. One of the first things I do when I get a new system is fire up KeyTweak and disable the Caps Lock key and the Insert key. I'm constantly hitting these keys by accident and putting my system into a state I don't want it in. This app also lets you remap keys to do entirely different things if you want.
• Fiddler. This tool lets you debug the HTTP stream between your browser and IIS. This has saved me multiple times over the years. When you're having a problem with a web page and you just can't seem to figure out what is going on, this can really shed a lot of light on things.