The latest release of Windows Vista has been released and I ran across a nice collection of screen shots that shows some of the new apps and the Vista look-and-feel. Microsoft has it packed full of eye-candy, but unfortunately I haven't found a big reason to trade up when it's released, especially if I have to pay for it. In fact, I'm actually kind of dreading it because it means more work for our product team to support an additional operating system.

About a month ago I installed Google's Desktop Search software on my dev computer. I've tried both MSN's and Google's Desktop Search products before but never found them to be very useful and instead of seeing those processes just sitting in my task list, I have always uninstalled them. Maybe because they were never installed on my main pc, I never realized the maximum benefit from them. This last attempt was done so I could check out the desk bar included in Google's product. The desk bar got old really quick, but I did stumble on the CTRL+CTRL trick that has proved quite useful. Hit the CTRL key twice and a little window pops up which let's you type in a search term. The search term can be for something local, like email or chat transcripts or something on the web. It can be a URL, a street address or even a calculation. Using the filetype: macro, it is surprisingly a very good way to search your source code too. I probably use it more than a dozen times a day. Give it a try.

I ran across a comical little write-up describing the The Website Development Process. The story makes the process look almost fun. I'm not sure if it was intended to be serious or not, but it's well worth just checking out the pictures. Seems like they took a lot of time and creativity.

I've seen some pretty impressive digital rendering before, but I had know idea it was this close to being mainstream. Microsoft will be releasing DirectX 10 on Windows Vista. DX 10 is a total re-write. I think gaming is going to jump to the next level. I also think it's a good idea for Microsoft to only make DX 10 available on Vista. It gives the gaming community and home users good incentive to move to that platform, even if business users have no motivation. Then again maybe it's not a marketing tactic since the article says "The new display driver or graphics model in Windows Vista, WDDM (Windows Display Driver Model), is the main reason for DirectX10’s exclusivity to the operating system".

We have been working on some simple site hosting to offer our GiftWorks customers. Something that would enable them to get some integration between GiftWorks and the web--something like online donations, update forms and/or blogs.  Obviously the blog hosting is up and running (the new software is hosting this site), but as far as finding a very nice desktop blog editor for our beta customers to use, I haven't come across anything (the closest thing I could find was Zoundry Blog Writer, which I used to make the previous posts on this site). That is until I tried the new Windows Live Writer from Microsoft. It seems to be working great and is very easy to use. It also has a developer SDK that allows adding some enhancements. I would have no problem recommending this to our customers--and will. 

There are a couple cool features, like showing a preview of the post in your actual website and some cool image properties.

Read the Writer team blog

In continuing to review the good and bad aspect of our last product cycle I ran across a discussion on the Coding Horror website called What is "Modern Software Development". The topic of the discussion is about identifying an essential checklist for good software development. There were existing lists from Joel Spolsky and Steve McConnell as well as new suggestions. It inspired me to compile an essential checklist for our development team. I used items from the original lists and added some of the suggestions from the discussion. Here is the list with how I feel we currently stack up.

1. Do you use source control?
Yes. All our source and documentation is in source control and backed up nightly, offsite. We use Subversion and TortoiseSVN.

2. Can you make a build in one step?
Yes. Each of our projects have build scripts so they can be built and packaged with single commands.

3. Do you conduct code reviews on a regular basis?
No. We have a small team of experienced programmers who all sit around a big desk in our dev room. This makes communication much easier, but it's still no excuse for being more formal about code reviews. This needs to happen.

4. Do you have a common code repository?
No. This is not so crucial for our small team, but as we grow it will be important. We find ourselves constantly asking "Hey Steve, where did you implement that XXX portion of code" so we can copy it in another place.

5. Do you have a bug database?
Yes. We use Bugzilla for recording bugs.

6. Do you fix bugs before writing new code?
No. We do fix bugs and supporting our customers is a top priority, but during a product cycle bugs are usually the last thing that are done and also the most likely to get short-changed.

7. Do you have an up-to-date schedule?
No. Scheduling is kinda done at the watercooler. This needs to be more formalized and done across the entire product team.

8. Do you have detailed activity lists?
No. We should be able to extract detailed activity lists from our specs. Currently this is not possible because our specs are not as detailed as they should be. I think these are important because it is a good litmus test for our spec process.

9. Do you have unit tests?
No.

10. Do you conduct regular usability testing?
No.

Whew. After going thru all that it appears we have a long way to go. It's not totally as bad as it seems. If there was a slight bit of doubt in answering the question, I listed No. Some of the items we do to a certain degree but I felt we need to address it better. Hopefully in the upcoming months we can improve on these items now that they are identified.

I've recently started using a program to re-map my Windows key on my keyboard. The name is HotKeys by Qliner Software. There are lots of programs I run during a days work. At this point, most of those programs have slowly floated their way to the top of the Windows Start Menu which is helpful by itself. But now they are one keyboard combination away with HotKeys. This cool little utility makes managing your key combinations a snap using a graphical view of your keyboard. All you need to do is call up the graphical keyboard and right-click on the key you want to map. If you know how to write macros using VBScript or some other language, you can program your keyboard to do almost anything.

Part of finishing up a product cycle involves a postmortem. It's a chance to reflect back and identify the positive and negative things that contributed to the success of a product release. Hopefully identifying the positive and negatives will help us improve the quality of our software and increase our efficiency in building products.

We have just finished up a particularly long and grueling cycle for GiftWorks Volunteers. While I'm sure the actual product will surpass the expectations of our customers, the process of getting there was not a model of efficiency. We had several slipped deadlines. I've spent a lot of time tracing the steps along the way, trying to come up with a short list of points to carry forward to the next project. One point that keeps coming up is time estimation. Our company and our competition work on "Internet time". Release early, release often. It is critical for us to deliver our products as fast (if not faster) than our competition. Our customers demand it. But our customers also demand quality, and that is the challenge.

Time estimation comes up at several places during a product cycle. When a product idea is formed there are always rough estimates made as to how long it would take to release. There are time estimates for coming up with product specifications, time estimates for doing the development and testing, time estimates for beta releases. There are even time estimates for coming up with time estimates. These estimates allow us to plan ahead and are necessary. From the very beginning, "do you think we can get this done for a fall launch?", "can testing begin next month?", "how long will it take to get feedback from customers?". Time estimates also have a major impact on the overall product, and I think that impact can easily be underestimated (no pun intended).

Early, "back-of-the-napkin" time estimates are sometimes used to set deadlines for a product release. I'll call these "artificial" deadlines. They are deadlines that are set based on information other than the project schedule created after a functional specification has been reviewed and all teams have had a chance to provide time estimates. The artificial deadlines may be marketing driven, competition driven or come from somewhere else. They are not wrong, but do add a degree of risk to the product cycle.

There are several variables that can be used to represent a product cycle. Here is how I picture the formula in my mind: Resources + Time is proportional to Functionality x Level Of Quality. Where the Level Of Quality is a constant, or at least I think it should be. Generally, the more resources or time you add to a project, the more functionality you'll end up with. For example, assuming constant resources and level of quality, a four month product cycle will yield more functionality than a two month product cycle. This may sound obvious to some. Typically a balance of resources, time and functionality is reached through an iterative process. With an artificial deadline, a fixed time variable, product managers adjust the number of features in proportion to the resources and the deadline.

In a company like ours, resources are generally fixed for a project. This means the only two variables we have to play with are time and functionality. Given this condition, artificial deadlines impose an artificial limitation on the level of functionality for a project. Not only is functionality fixed, it is also fixed before specifications are drafted. This could put you in the position of not having enough functionality to meet customer expectations when the project is done. And worse, you are likely to only come to this realization late in the product cycle. Not a good situation, especially with artificial deadlines which are there usually because there are external dependencies on a date. Now, not only is the project in bad shape, so are the external dependencies. 

There is another side-effect of artificial deadlines. There is very little margin for error. If there is slippage in one part of the project, everything that depends on it will have less time to get done. This usually has a direct effect on the quality of the product because internal testing and customer testing happens at the end of the project.

So what's my point here? My intent was to examine how time estimates affected our latest project. In particular, time estimates used to guide artificial deadlines. My thoughts are to avoid artificial deadlines altogether. But sometimes they are necessary and this is where time estimates are especially critical. When early, rough estimates are used to guide artificial deadlines, you have to be very careful to assess the accuracy of those estimates and adjust those deadlines accordingly. I think this is one area that contributed to the slips we endured in our latest product cycle. In each case we underestimated the work involved in getting to where we wanted to go. Luckily our external dependencies were not too rigid. Moving forward we need to identify when a deadline is artificial and make sure that it is the right thing to do. If we decide to continue using an artificial deadline (which may be appropriate) then we had better be sure about our confidence in the accuracy of our estimations, or account for that risk in our plans.