• 6-speed manual transmission
• engine with variable valve timing (later ammended to "interesting technology")
• seat heaters (for the wife!)
• 4-wheel disc brakes
• under $20k
• 4-wheel independent suspension

When I was buying my last car in 2003, the car that came closest to my list was probably the Nissan SE-R Spec V, which missed out on the independent suspension and seat heaters.  The other two cars I seriously considered were the Jetta (missing out on the 6-speed and independent suspension, but pretty close to the $20k price limit) and the Subaru WRX (missing the 6-speed and seat heaters, and really too far from $20k for serious consideration).

In the end I picked the Jetta over the Nissan because the Jetta came across more as "premium" small car while the Nissan seemed more like a cheap car with an uprated suspension and engine.  Four and a half years later, I still feel the same--I think I would have been disappointed with the low-cost feel of the Nissan, although I'm certain it would have been much more reliable with the Jetta.

These days, I think the car that most closely matches my criteria is the Mazdaspeed 3.  It's not under $20k, but it's reasonable close (and I realize that $20k is pretty unrealistic for a car these days) and it's as quick as our Corvette.

So how does this all relate to American car companies?  Simple:  As you've probably noticed, I haven't mentioned a single American car that's come close to my new car criteria. 

And that bugs me, because I really want to buy an American car.  I'd much rather buy an American car than a foreign one, but nothing they offer was close enough to my requirements to merit consideration.  The biggest problem for me is that the American car companies offer very few cars with manual transmissions.  I'd often say, "Cavaliers and Corvettes"--those were the only two Chevrolet cars offered with manual transmissions; everything else was strictly automatic.

In 2003, probably the closest American car to my criteria was the Dodge Stratus R/T, but the MSRP on that was like $27k.  I think the final price on that Stratus would have been close to the $21.5k I spent on the Jetta, but even thinking about trying to get a car salesman down from $27k makes me feel ill--the endless "let me run this past my manager" smoke breaks, the "I'm losing money on this deal" BS, the constant pushing of unwanted paint treatments.

I think that at the time, American car companies were trying to make customers feel like they got an expensive car for an incredible discount.  But it backfired for customers like me, because I never stepped into a Dodge dealership since I didn't want to deal with hours of salesman BS while they whittled down the price $200 at a time.

Dodge, are you listening?  Do you care?

I'm not sure why the American car companies don't want to build a car that I'd consider buying.  Certainly I'm in a vast minority since I prefer a manual transmission.  But the German and Japanese manufacturers have no problems offering a variety of cars to me with manual transmissions.  Why don't the American manufacturers?  I guess it's because the sales volume of manual tranmission cars would be low enough that they can justify losing that business.

Oh, well.  Perhaps someday they'll building something that comes close enough to my list that I'd consider buying. 

I'm not holding my breath, though.

Ben

    class OrderAttribute
    {
        public int OrderID;
        public int AttributeID;
    }

    class OrderAttributeDataLayer
    {
        public static OrderAttribute[] GetOrderAttributesForOrderID(int orderID)
        {
            SqlConnection connection = new SqlConnection();
            connection.Open();

            string sql = "SELECT OrderID, AttributeID FROM OrderAttribute WHERE OrderID = " + orderID.ToString();

            SqlCommand cmd = new SqlCommand(sql, connection);
            SqlDataReader reader = cmd.ExecuteReader();

            List<OrderAttribute> tempList = new List<OrderAttribute>();

            while (reader.Read())
            {
                OrderAttribute orderAttribute = new OrderAttribute();

                orderAttribute.OrderID = Convert.ToInt32(reader["OrderID"]);
                orderAttribute.AttributeID = Convert.ToInt32(reader["AttributeID"]);

                tempList.Add(orderAttribute);
            }

            reader.Close();
            connection.Close();

            return tempList.ToArray();
        }
    }

And finally, the code to display the total of all rush orders:

public static void DisplayRushOrderTotal()
{
     Order[] rushOrders = OrderDataLayer.GetRushOrders();

     double totalValue = 0.0;

     foreach (Order order in rushOrders)
          foreach (OrderLine orderLine in order.OrderLines)
               totalValue += orderLine.Quantity * orderLine.UnitPrice;

     Console.WriteLine("Total rush order value = $" + totalValue.ToString());
}

public static void DisplayRushOrderTotal()
{
     SqlConnection connection = new SqlConnection();
     connection.Open();

     string sql = "SELECT SUM(ol.Quantity * ol.UnitValue) FROM OrderLine ol JOIN OrderAttribute oa ON ol.OrderID = oa.OrderID JOIN Attribute a ON a.AttributeID = oa.AttributeID WHERE a.AttributeName = 'rush'";

     SqlCommand cmd = new SqlCommand(sql, connection);
     double totalValue = Convert.ToDouble(cmd.ExecuteScaler());

     connection.Close();

     Console.WriteLine("Total rush order value = $" + totalValue.ToString());
}

• Which do approach is more clear and concise?
• Which could be developed faster?
• Which would perform better?
• Which would be easier to debug and fix?

Finally, ask yourself this:  Which is the better approach?

Ben

public class Attribute
{
     public int ID;  
     public string Name;
}

public class Order
{
     public int ID;
     public Attribute[] Attributes;
}

CREATE TABLE Order
(
OrderID INT
)

CREATE TABLE Attribute
(
AttributeID INT,
AttributeName VARCHAR(30)

)

CREATE TABLE OrderAttribute
(
OrderID INT,
AttributeID INT

)

public class ObjectAttribute
{
public int OrderID;
public int AttributeID;
}

public class Order
{
     public int ID;
     public OrderAttribute[] OrderAttributes;
}

foreach (OrderAttribute oa in order.OrderAttributes)
{
     Attribute = OrderAttributes.GetAttributeByID(oa.AttributeID);
     // do something with the attribute here
}

foreach (Attribute attribute in order.Attributes)
{
     // do something witht he attribute here
}

• You need a reasonable amount of network knowledge to get ISA 2006 working.  My networking knowledge is ok, not great, and when I first installed ISA 2006, *nothing* worked.  The network card plugged into the cable modem couldn't even get an IP address.  It turns out that out-of-the-box ISA 2006 blocks *everything*, so you have to enable things like DHCP traffic from localhost to the external network before anything will work.
• ISA 2006 should really run on a box that is solely dedicated to being an edge server.  I have one spare box that I use as server, so it ends up running everything--ISA, IIS, SQL Server, file and print sharing, blah, blah, blah.  While ISA 2006 is fine with this configuration, I've realized that putting anything other than ISA on an edge server is a security disaster waiting to happen.  I'm hoping to set up a dedicated ISA 2006 server in the next couple of months.
• There's some issues with Windows Server 2003 SP2 and ISA 2006, mainly due to networking changes in SP2.  There's some web sites that list some workarounds, but it wasn't always obvious what exactly was the causing the problems.  I've been able to work around the problems, and I hope to have another post with some specific solutions I've found.
• There's some wacky problems with daily ISA 2006 report generation when you're logging data to SQL Server.  I never quite figured out if the problem was due to me running SQL Server 2005 on the same box, or something else.  In any case, logging ISA 2006 to SQL Server doesn't seem to be a great idea, as the amount of data is a bit ridiculous--like 40MB of log data in SQL Server per day for my tiny network.  That amount of data would be fine if it was high value, but socket connection logs?  Do you really need that data in SQL Server?

Overall, though, ISA 2006 server kicks butt--it's very fast even on slow hardware, and it's easy to configure access rules.  My favorite rule is one that blocks access to many of the dumb advertising sites like advertising.com, doubleclick, etc.  So, instead of getting a dozen ads on every web page, I get a green box that says "Insert annoying advertisment here". Score!

From what I've seen thus far, I'd certainly recommend it for SMB, and probably for larger businesses, also.  It seems cost-effective compared to similar hardware solutions, and I haven't run into a downside yet.

Plus, it generates nice HTML traffic report summaries.  So, if you're *really* bored, you can check out traffic in my basement:

http://basementnet.dyndns.org/isa

Have fun!

Ben

• Outdated hardware/software (e.g. 16-bit Delphi 1.0 app running on Windows 3.1)
• Quick bug fixes and hacked-in additional functionality over the years have turned the codebase into a fragile knog of spaghetti
• Current code doesn't provide enough scalabillity and/or reliability
• Etc, etc, etc.

Typically the solution I hear from developers is this: "We need to stop trying to hack in additional features and take a year or two to rewrite the app from scratch."  Then they'll usually mutter something about how management would never allow them to do something like that.

Now, I'm a developer and not a manager, but in this case I'll side with the managers for several reasons:

1. The cost to re-implement current functionality can't be justified because at the end of the project you'll basically have the same functionality that you started with.  But boy, you've blown through a lot of budget dollars!
2. There's the opportunity costs of not having resources available for implementing new functionality, while (unfortunately) your competitors are.
3. There's no guarantee that the new codebase will be any more maintainable/scalable/faster than the current codebase.  Likely?  Yes.  Guaranteed?  No.

Alternatively, I've been approaching problems like this with a technique I loosely refer to as "software evolution."  It's deceptively simple, but over time I've found it to be a effective and workable solution.

First, you need to set mid- to long-term goals for the system.  Usually, these are fairly generalized, broad goals such as, "we need to move such-and-such data off the mainframe and onto PCs" or "we need to improve the reliability of this interface between these two computers."

Next you go forward with your usual workload as you have in the past, fixing bugs and implementing new features, but with one subtle difference:  you now apply the following test to every change you make to the codebase:

Does this change bring me closer to my goal?

If the change you have proposed doesn't bring you closer to your stated goal, don't do it!  Instead, rethink your solution until you come up with an approach that does.

As a simple example, assume that long-term goal is to move your mainframe data onto PCs.  Your manager has just come to you, asking for an enhancement that will require a new database table.  Where will you put this new table?

If you put the new table on the mainframe, the test will fail; the change will put more data on the mainframe, which is exactly what you're trying to get away from.  Of course, putting the data on the PC might cause some additional headaches for your current task (for example, what if you need to access this data from the mainframe?).  But it turns out there is no alternative: putting the data on the mainframe moves you further from your goal, and converting all the data en masse not practical.

In the end, what you're doing is spreading the risk and development effort of the conversion over many small projects, with the bonus that you're continually adding new functionality or bug fixes.  And as you use this approach over time, you will slowly (but surely!) see your systems evolve into what you want them to be.

Which is a good thing.

Ben