Well some people like to blog about what they are currently reading, but I often wonder if they ever finish the book or if they simple skimmed through it a little bit and it's now gather dust on a shelf. I just finished reading Extreme Programming Explained by Kent Beck. It was very interesting to read and I suggest picking it up if you are interested in the topic of Extreme Programming.

I'm really getting tired of waiting for computers to do things; boot, shutdown, open Visual Studio, build. I feel like I spend more time waiting for the computer to do something then actually getting work done and this is very frustrating. I like my laptop and unfortunately it's not dual core, but I've decided that for the amount of mobility that I need it can still handle the job. What I do what to do is build a new desktop development box that I can use when working in the office since this is where I do most of my work, outside of the day job anyways. I've gotten a bit out of touch with the hardware world lately so I was hoping to solicit some feedback in a few areas. Here is a list of the general specs I've laid out.

Quad Core Processor – I realize that this is still a bit vague since some argue that a dual core with a faster speed is better that a slower quad core, but I hope to get the fastest quad core processor for a reasonable price when I make the purchase.

Motherboard – This is where I've gotten a bit rusty. Does anyone have any suggestions on brands and specs that I want to look for?

Vista Ultimate 64 bit – Yeah, Yeah don't do it, Vista sucks. I'm going to do it anyways.

4GB of RAM – Anything important here besides speed and response time?

16-30GB Solid State Hard Drive – This one I think is the sweet spot. The last moving part on the computer is the hard drive and common sense says that means it's the real bottleneck. I hope to get a small solid state hd that will hold the OS, VS2008, and maybe Office depending on price vs size. My one issue here is I haven't seen any 3.5 inch solid state drives.

Large Secondary Hard Drive – A regular SATA hard drive to handle everything else that isn't used all the time. I'm thinking a WD Raptor for this.

Video Card(s) – Yet again I'm going to need to do some research here or get some feedback. What specs do I need to look for here?

2 X 22 inch Widescreen Monitors – I haven't decided on anything specifics here, I just know I want 2 that are exactly the same so they are at the same level.

Case – A really, really quiet case. This is going to involve research too.

Any feedback that anyone has would be great.

    Well its official The Gifford has turned me into a code coverage addict. After he helped me through writing my first unit test using NUnit the concept slowly started sinking in and I'm now addicted to code coverage. Writing NUnit tests is so easy that I don't understand why everyone won't do it, which is causing me to get a bit frustrated with people as it gives me the impression that they just don't care. I can't remember the number of times that I have gotten rather pissed because someone has changed my code and broken functionality and in some cases I've even broken my own code when I've had to go in and make changes after not looking at it for some time. Unit testing can minimize these hair pulling moments by giving you more confidence that what was supposed to be happening before you touched the code still happens after you touched it. If someone is in muddling around in your code and breaks something, you'll know immediately when they check in and the test doesn't pass on the build server. It all comes down to code quality and I have begun to notice recently that code quality everywhere sucks.

    If you're not using unit testing of some sort then I think it just boils down to pure ignorance. Either you see the value of unit tests, but don't know how to write them and are too lazy to exert the effort to learn how, or you are just too ignorant to see the value of them. I fell into the first group. I've always seen how they could be helpful, but never took the time to learn how to do them. In the last couple weeks I've been really thinking about code quality with the product that I am building with a couple partners. We decided to build this product because we had gotten stuck working with another product that we thought had many problems and was a pain to work with. I realized that we were starting to walk down the same path, rushing to get a beta out, sacrificing design and architecture for deadlines. There are plenty of poor applications on the market and I don't want to be contributing to that. I want to produce a quality product or nothing at all because in the long run if we produce a poor quality product then we get stuck supporting that poor quality and our customers are stuck working with it. While assessing quality I kept coming back to our lack of unit testing and the fact that things kept breaking that worked fine the day before. This motivated me to overhaul the build server so that it runs NUnit tests automatically and then uses NCover to provide statistics on the code that is covered by unit tests and the code that is not covered. Then to take it one step further I built a screensaver that runs on the monitor of the build server that displays the overall percent of code coverage from the project in bright flashing red while it is under the coverage goal. (Currently FloFactory is at 9.5% code coverage with a coverage goal of 50%.) I look forward to the day that that text turns green to indicate that we have met our code coverage goal (and then I'll raise the goal).

    I'm sure plenty of people would argue about the value of unit testing, pointing out various short coming with unit testing which I am sure are all valid in certain scenarios, but if you're following a tiered structure for your application, keep your logic out of the UI and keep your data access separate, then you should have an entire service layer that can be unit tested. Does having unit tests mean your code is perfect, of course not. It's not a silver bullet for quality but it is one tool to provide a bit more certainty about an application.

    Where I am really struggling is motivating others to improve their code quality, understanding the importance of testing and getting them to write even one unit test. I realize that unit testing can't cover your entire application, but it's a start and if you start thinking about how you structure your application you'll starting seeing better ways to design things so that you can properly test them using such things as mock objects and inversion of control containers. The Gifford told me once that he goes by the statement "You don't have write unit tests, but don't break mine." Whereas I like this statement, I don't think it motives any one to write a single unit test, so I'm adding onto this by trying to make the statistics more visible. Hopefully if someone checks in code that lowers the overall coverage percent, that they can see very clearly on the build server screensaver, they may feel more motivated to raise that number.

    As for myself, I'm going to keep digging into ways to increase quality so that the final product is stable and worth using. One last thing to point out is that if you plan to get started unit testing and are going to use NUnit then I would suggest picking up a copy of Resharper. It allows you to run your NUnit tests extremely easily from Visual Studio taking some of the headaches out of writing them.