June 2003 - Posts - Darrell Norton's Blog [MVP]

The Amazing Baconizer

The Amazing Baconizer shows how two items are linked by consumer preference on Amazon. Very entertaining. Courtesy of Chris Sells' blog.

Posted Jun 30 2003, 10:39 AM by darrell with no comments

Build fast, fix faster

Johanna Rothman writes about frequent builds and automated smoke tests in Build Fast and Fix Fast. My favorite quote from her post:

"The faster you want the project to go, the more frequently you need to build."

It seems counterintuitive, but it ends up working for the reasons she explains in the blog post. As stated in my recent review of the book The Goal, the book challenges ideas that are intuitive throughout. For example, to speed up the factory, the plant manager had to have some workers not do anything for maybe hours per day.

If you are thinking about trying daily (or more frequent) builds, it is going to take some work but the payoff is there. Initially the discipline necessary to get your application to a daily build-able state and setting up the automated build and unit tests will take a lot of time and will seem like development would be faster without it. However you will come to love it the first time it gives you an early warning on what would have been a big problem.

Johanna also writes in GUI Requirements and Text Documents that using a paper prototype is the best method for determining GUI requirements. She writes, "monolithic requirements documents are too hard to read, too detailed, and insufficiently detailed, all at the same time." I cannot agree more. In a recent project I worked on, the use cases totaled 1700 pages. Unfortunately these were not complete until 1 month prior to when we, the developers, were supposed to be done, but that is another story. Of those 1700 pages, we probably ignored half since they overspecified, were not detailed enough, or were incomprehensible. Sad to say, but we could have developed faster by removing the requirements team (which was as large as the development team) and working directly with the end users.

Posted Jun 30 2003, 10:38 AM by darrell with no comments

Configuration Management Article

Eric Sink writes about version control features beyond CheckOut and CheckIn. This is a good read for anyone using a version control tool (which should be everyone), especially for those using SourceGear's Vault (Eric is CEO of SourceGear) or SourceSafe.

Posted Jun 30 2003, 10:37 AM by darrell with no comments

The Goal - A Process of Ongoing Improvement

The Goal is an instructive business fiction novel. What does that mean? It means the author, Eli Goldratt, uses a fictional story, replete with characters, a plot, conflict, etc., to illustrate his business concepts, which makes it a very fast read. It was so absorbing that I finished it in 4 days!

Alex Rogo is plant manager for a plant that faces closure in three months if they do not turn things around. Unfortunately, he and his management team think do not know what to do, since their “efficiency numbers” continue to improve. Alex turns to Jonah, a former physicist friend turned business consultant for help. Jonah refuses to help but instead sets Alex in the right direction, illuminating different paths when he gets stuck. This causes the reader to think about what should be done before an answer is given, Socratic method-like.

How is this relevant to the software development? I read this book after seeing it reviewed on Jeff Sutherland’s SCRUM Log. The entire concept of trying to figure out what really makes money, despite the fact that Alex runs a manufacturing plant, helps set the focus for our work as software professionals. Are UML diagrams, technical specifications, hot new technology, or heavily-specified processes the answer? Not necessarily, especially not if it doesn't solves our customers’ problems. Jeff presents some answers on his log, but I think it is more important that all of us, like Alex, go on our own journey of discovery.

I will only post a review of a book if I have rated the book 5 stars on Amazon. All book links are Amazon Associates links. I will only use the referral credits to purchase more technology or business-oriented books (no fiction books or anything). In short, I will not peddle crap to you just to get referral fees.

Posted Jun 26 2003, 07:54 AM by darrell with no comments

Performance Counter Consolidation - Another Plus for Yukon

While reading an article in SQL Server Magazine, I learned that the ADO.NET connection pool counters are on the system executing ADO.NET code. SQL Server performance counters, on the other hand, are on the system with SQL Server. Since most apps deploy with the database on one server and the web/business/data-access logic on another, this means these related performance counters are in different places.

But with the coming of SQL Server Yukon, if you use the System.Data.SqlServer namespace (instead of SqlClient) and run your data access code on the database server, all ADO.NET and SQL Server performance counters will be easily accessible on one system. For system administration and management, this is a good thing.

Posted Jun 25 2003, 06:16 PM by darrell with no comments

Problem with VS.NET Design View

A coworker and I are having a problem with the design view in VS.NET. I can see any DataSets that we have put on one page in design view, but he cannot. I look in the resx file and the DataSets are all there, but they refuse to show up on his computer. Also, some pages will not show DataSets in design view on either of our computers.

This project was upgraded from v1.0 to v1.1 of the .NET Framework. That might have something to do with it. I do not think it is a side-by-side installation issue, because it works for me both before and after uninstalling VS.NET 2002 and v1.0 of the Framework. I saw one post on Google Groups mentioning that this might be a resx file problem, but I tried running the ReGenResx tool from GotDotNet on one file in question and it did not seem to solve the problem.

Is anyone else out there having problems with the designer dropping DataSets and/or refusing to show them? If so, have you come up with a solution?

Posted Jun 25 2003, 03:54 PM by darrell with no comments

Three new Application Blocks from Microsoft!

Three new Application Blocks!

The Configuration Management Application Block - store configuration settings in an XML file, a database, the registry, or a custom data store.
The Updater Application Block - based on the AppUpdater sample on GotDotNet, it provides a pull-based solution to keeping applications current.
The User Interface Process Application Block - helps you abstract out the User Interface workflow and state management from the actual WebForms.

These only work on v1.1 of the .NET Framework.

Posted Jun 25 2003, 12:45 PM by darrell with 3 comment(s)

Data Access Block v2 Released!

Version 2 of the excellent Data Access Application Block was made available on June 20 (not even mentioned on the GotDotNet home page!). You can download the RTM here.

Posted Jun 24 2003, 07:51 PM by darrell with no comments

Third normal form (3NF) is not the end goal

SBC recently posted on .NET Weblogs about designing databases prior to development. While a good post, one statement got me:

"normalization (at least 3NF)..."

While third-normal form is a general guide in designing a database model, it is not the be-all end-all goal.

The logical model is supposed to be taken to 3NF and then adjustments made for performance, ease-of-use for developers, etc. These adjustments back away from 3NF, tending towards 2NF. For example, say you have an address table that includes the following fields: AddressID, StreetAddress, City, State, ZipCode. Seems reasonable, right? Well, according to at least 3NF this is wrong. You see, I can determine the City and State from the ZipCode. In fact, as the US post office continues with the zip code extensions (12345-6789-01), they do not even need the street address either (that's the 01 in the zip code). This means that the City, State, and maybe the StreetAddress are facts about the non-key field ZipCode, a clear violation of 3NF. This is just an example, and my apologies to anyone living outside the US, but I think you can understand the point I am trying to make.

Who knows about the forms after 3NF? There is Boyce Codd Normal Form (BCNF), a.k.a. fourth normal form, and fifth normal form (5NF). BCNF and 5NF are rarely used in real-life. This is not to say that there is anything wrong with them; the principles of removing redundancy are key to the relational model. It is just that usually the effort-return tradeoff is not favorable to making the design this strict. Actually BCNF is a good normal form for developers. BCNF (and also 5NF) attempt to minimize the number of fields involved in a composite key, ideally to 1 field. This will make developers happy (see my ranting post), and now we have an academic/theoretical reason to back us up!

So what is the right amount of normalization? Which form: 1NF, 2NF, 3NF, BCNF, 5NF? The answer, as always, is it depends. Sometimes for performance reasons you will want to denormalize to 2NF. Other times, pushing to BCNF is a good idea. It depends on the project, the effort-benefit tradeoff in maintaining the data, etc. As a rule of thumb, though, it is better to logically model to 3NF or BCNF, and then back away where the complexity of the model outweighs its usefulness or excessively inhibits performance.

See William Kent's A Simple Guide to Five Normal Forms in Relational Database Theory.

Note: The title of this post might seem to indicate that I do not believe in 3NF or database normalization. This is not true! I am against the blind adherence to categorical statements such as this that pervade software development. Also, I am not saying that SBC wrote his post with this blind adherence in mind. It happened to be his post that used the statement that I challenge. Let me reiterate that I think SBC's post is well-thought-out and has some very good ideas.

Posted Jun 24 2003, 12:46 PM by darrell with 5 comment(s)

Joe Walnes has a blog!

Joe Walnes, who works at ThoughtWorks in England, has just revived his blogging efforts. This one is on agile software development. Subscribed.

Posted Jun 24 2003, 08:53 AM by darrell with no comments

SQL Server Yukon Article in .NET Magazine

.NET Magazine has an article about SQL Server Yukon in the June 2003 issue. Besides the usual stuff (C# and VB.NET support for stored procs, UDFs, etc.), there were a few new things:

Microsoft is going to make it as easy to change where the data-access code executes as changing a namespace. By changing the System.Data.SqlClient to System.Data.SqlServer, all data-access code will execute on the SQL Server. I still think being able to execute all data-access code on the same tier as the database will be a huge performance gain. Watch the TPCC benchmarks!
SQL Server Workbench is fully-integrated into VS.NET, so you get all the great Intellisense and debugging features.
Implementing the new INullable interface handles NULL values. This will eliminate many lines of code that deal with null values.
XML is a native datatype. IMO, this will probably be the deathblow to XML-databases, since after Microsoft does it, IBM and Oracle will do it too. There never really was a need for XML-specific databases anyway. XML is a way to markup data, not separate it (like the relational model).

Posted Jun 23 2003, 01:01 PM by darrell with no comments

Visual Studio .NET keyboard shortcut

When you open VS.NET, if you have the Start Page show your recent projects, you can use the arrow keys to change the selected project and then click the spacebar to open that project - no mouse necessary!

Posted Jun 23 2003, 01:00 PM by darrell with 3 comment(s)

Re: Optional Parameters in SQL Server Search Queries

Steve Eichert writes a good post on keeping search queries clean using optional paramters. The example given works as long as the fields are all non-null. If the fields can be null and you want to search on that field, you only have to modify the SQL query slightly. For example, say ManagerID can be null (if the employee is the CEO of the company).

Before

SELECT * FROM Employees e
WHERE
(@EmployeeID IS NULL OR e.EmployeeID = @EmployeeID)
AND (@DepartmentID IS NULL OR e.DepartmentID = @DepartmentID)
AND (@ManagerID IS NULL OR e.ManagerID = @ManagerID)
AND (@LocationID IS NULL OR e.LocationID = @LocationID)

After (added text in red)

SELECT * FROM Employees e
WHERE
(@EmployeeID IS NULL OR e.EmployeeID = @EmployeeID)
AND (@DepartmentID IS NULL OR e.DepartmentID = @DepartmentID)
AND (@ManagerID IS NULL AND e.ManagerID IS NULL OR e.ManagerID = @ManagerID)
AND (@LocationID IS NULL OR e.LocationID = @LocationID)

Posted Jun 23 2003, 10:20 AM by darrell with no comments

Database Modeling - what not to do

using SQL Server 2000;
using insane data modeling standards;

First, do not have a compound primary key if one of the fields in the table is an Identity. An identity is, by definition, unique. All you are doing is adding more work and aggravation for everyone (except maybe yourself, if you only do the data modeling) for no benefit. Therefore, if you have a compound primary key for a table and one of the columns anywhere in the table is an Identity:

You are wasting disk space by copying all the rest of the primary key as foreign keys in other tables when a single, simple integer will do.
You are degrading performance by forcing joins on 5 columns (yes, in my case it was 4 columns PLUS an Identity column).
You are forcing developers to have to code around their a** to get to their elbow, since they must code in joins that are 3-4 fields too many.

Second, primary key != clustered key. The problem here is that what was designated as the primary key was also the clustered key. While this puts all of the important fields in a clustered key and thus should theoretically improve performance, this is still a bad design. The clustered key should include the fields most often searched on and which narrow the result set substantially. This speeds up queries dramatically. But this does not have to be the primary key. I can join on an Identity (integer) field very easily, quickly, and still set the clustered key to 4-5 columns no sweat. Plus the majority of the time, performance is almost as fast for a nonclustered index on an identity field as for a clustered index on an identity field.

Scott Ambler writes about assigning keys effectively (a link to the page where this is from can be found in the More Info section below):

Avoid “smart” keys

Consider assigning natural keys for simple “look up” tables

Natural keys don’t always work for “look up” tables

Your applications must still support “natural key searches”

More Info

Data Modeling 101 - by Scott Ambler on the AgileData site.
SQL-Server-Performance.com posted an excellent interview with David Gugick, SQL Server performance expert. If you read both pages of this interview and follow everything in it, then you will be 80%+ of the way "there."
Kalen Delaney's book Inside Microsoft SQL Server 2000 (Amazon Associates link) is the classic treatise on SQL Server's inner workings. If you are a DBA or database developer, buy this book.
Kalen Delaney also had a series of 14 articles in SQL Server Magazine ending in October 2002 about query tuning (including tons on indexes, clustered and non-clustered keys, etc.). Unfortunately, after July 1st you will need to be a subscriber to access the article archive.

Posted Jun 20 2003, 02:22 PM by darrell with no comments

Convert Windows Server 2003 into a Workstation

If you can't wait until the next workstation release of Windows (Longhorn), then convert Windows 2003 Server into a workstation! This article goes step-by-step in great detail with screenshots about what exactly you need to do.

Apparently Windows Server 2003 is better on memory management, security, and stability. So the use of Win2k3 as a workstation has been making the rounds among some developers lately. Maybe I'll try it when I get some downtime at work.