I'll have to add to this in the near future.  From Jeff Atwood: http://www.codinghorror.com/blog/archives/000666.html

1. Every programmer shall have two monitors

   With the crashing prices of LCDs and the ubiquity of dual-output video cards, you'd be crazy to limit your developers to a single screen. The productivity benefits of doubling your desktop are well documented by now. If you want to maximize developer productivity, make sure each developer has two monitors.

2. Every programmer shall have a fast PC

   Developers are required to run a lot of software to get their jobs done: development environments, database engines, web servers, virtual machines, and so forth. Running all this software requires a fast PC with lots of memory. The faster a developer's PC is, the faster they can cycle through debug and compile cycles. You'd be foolish to pay the extortionist prices for the extreme top of the current performance heap-- but always make sure you're buying near the top end. Outfit your developers with fast PCs that have lots of memory. Time spent staring at a progress bar is wasted time.

3. Every programmer shall have their choice of mouse and keyboard

   In college, I ran a painting business. Every painter I hired had to buy their own brushes. This was one of the first things I learned. Throwing a standard brush at new painters didn't work. The "company" brushes were quickly neglected and degenerated into a state of disrepair. But painters who bought their own brushes took care of them. Painters who bought their own brushes learned to appreciate the difference between the professional $20 brush they owned and cheap disposable dollar store brushes. Having their own brush engendered a sense of enduring responsibility and craftsmanship. Programmers should have the same relationship with their mouse and keyboard-- they are the essential, workaday tools we use to practice our craft and should be treated as such.

4. Every programmer shall have a comfortable chair

   Let's face it. We make our livings largely by sitting on our butts for 8 hours a day. Why not spend that 8 hours in a comfortable, well-designed chair? Give developers chairs that make sitting for 8 hours not just tolerable, but enjoyable. Sure, you hire developers primarily for their giant brains, but don't forget your developers' other assets.

5. Every programmer shall have a fast internet connection

   Good programmers never write what they can steal. And the internet is the best conduit for stolen material ever invented. I'm all for books, but it's hard to imagine getting any work done without fast, responsive internet searches at my fingertips.

6. Every programmer shall have quiet working conditions

   Programming requires focused mental concentration. Programmers cannot work effectively in an interrupt-driven environment. Make sure your working environment protects your programmers' flow state, otherwise they'll waste most of their time bouncing back and forth between distractions.

Jeff Atwood pointed out a very interesting XP change diary by James Shore. 

"It was 2002. The .com bust was in full slump and work was hard to find. I had started my own small business as an independent consultant at the worst possible time: the end of 2000, right as the bubble popped. I had some noteworthy successes doing what I loved: coaching agile Extreme Programming (XP) teams in doing great work for a valuable purpose. And then the work dried up.

Eventually I admitted that I was going to have to find some "real" work to fill the gap. I took a contract job as a programmer on a team customizing some web software for a large institutional customer. This team was the opposite of agile. I was bored and frustrated. It didn't take me long to remember Martin Fowler's advice. As a peon, could I make the kinds of changes I made as a (damned good!) XP coach? Or would they kick me out, causing me to change organizations a little more abruptly?"

The full diary can be found here: http://www.jamesshore.com/Change-Diary/.  I highly recommend reading it, even if you aren't that interested in XP.

After moving the CruiseControl.NET server to a virtual instance of Windows Server 2003, we've been having problems with NDoc hanging.  I've noticed previously that NDoc was apparently leaking memory thus forcing me to reboot the server every night.  I think it may be opportune time to swap out the alpha version of NDoc we've been using up to this point for Sandcastle, Microsoft's (beta) code documentation generator.

The idea was to make the autobuild system hardware independant, which I think we achieved, however I wonder if it was worth the extra effort. I think it will be beneficial in the long run since the build is dependant upon the following apps/tools which are not is source control: .NET 2.0, a local SQL Server 2005 instance, CruiseControl.NET, and Perforce.

So far I'm pretty impressed with Virtual Server, especially the ability to mount ISO images directly to the guest CD drive. I can't believe I haven't used VS before today.

The only strange issue we ran into was a "VMRC Negotiate Authentication" problem. Everytime we tried to reconnect to a instance authentication would fail. Setting the authentication mode from Automatic to NTLM fixed this issue for us.

Note: For visitors of your site, this entry is only displayed for users with the preselected language English/English (en)

It only took me several years to get around to it, but I finally did it; I installed a blogging package, dasBlog!

I'm not sure why it took me this long, but I hope to use this space as a centralized storage of random thoughts and notes for future reference for myself - and anyone else if they're interested.

After logging in, be sure to visit all the options under Configuration in the Admin Menu Bar above. There are 26 themes to choose from, and you can also create your own.

 

I just relearned a valuable lesson today, make sure when you are using multiple libraries in your C++ project, that they all use the same runtime library.  For instance, if you have one library set to use the Multi-threaded (/MT) runtime library, then make sure the consuming project also is set to use the Multi-threaded (/MT) runtime library.