CodeThinked

Most people are quite familiar with the Singleton pattern. This is probably one of the most widely used and widely abused patterns in existence today. The Singleton pattern forces its users to only access a single instance of a class. This is usually accomplished by making the constructor of a class private and then providing a static property or method through which this single instance can be accessed. A simple implementation would look like this:

public class Singleton

{

    private static Singleton instance;

    private Singleton()

    {

    }

    public static Singleton Instance

    {

        get

        {

            if (instance == null)

            {

                instance = new Singleton();

            }

            return instance;

        }

    }

    public String DataItem { get; set; }

}

In this example I have included a single data member to show you that these are just normal instance members like you would have in any class. Then you can see that we have a static Instance property and a static instance private data member. You would consume this class like this:

Singleton single = Singleton.Instance;

single.DataItem = "value";

There are several complaints that people have about this pattern. First of all is the way in which it is instantiated. Calling Singleton.Instance to get your class is not exactly a standard, what happens when you one day decide that this class should no longer be a singleton? Well, you have to touch every part of your application that calls the "Instance" property. You'd probably be better off wrapping your Singleton creation inside of a factory method to begin with. At least then you won't have to change every part of your code that accesses your singleton.

Other complaints that people have involve memory leaks, holding onto resources that should be let go, global variables, testing, etc... There are quite a few people who feel very strongly about the fact that Singleton is actually an anti-pattern. Well, let me first say that Monostate will not make any of these people happy.

The Monostate pattern tries to accomplish something similar, but in a very different way. Generally speaking, the Monostate pattern attempts to hide the fact that a class is only operating on a single instance of data by using static data members. This way, consumers of this class will feel as if they are instantiating their own instance, but in fact will be accessing static data.

The Monostate pattern is nothing new. As far as I can tell, it was first described in the September 1996 issue of the now defunct "C++ Report" magazine. I will first start off by showing you how the Monostate pattern is instantiated and used:

var single = new Monostate();

single.DataItem = "value";

You may be looking at this and saying, well, he is just creating a new class. I'm not sure how this helps me with the Singleton pattern. And you have inadvertently unearthed the single biggest complaint that is unique to the Monostate pattern. You cannot tell when you are using a Monostate object other than to look at its internal implementation. This is how that above code would be implemented:

public class Monostate

{

    private static string dataItem;

    public string DataItem

    {

        get { return dataItem; }

        set { dataItem = value; }

    }

    public Monostate(){ }

}

As you can see, all we do is use instance properties with static private data members. It is quite the sneaky little pattern. Everyone who uses the class will not know that they are dealing with a single backing data item. This could be good or bad depending on how you look at it.

The Monostate pattern does not solve all of the problems that the Singleton pattern has, but it does provide an interesting way to keep single data values, while still allowing your classes to have multiple instances. Monostate classes are also easier to inherit from and modify than their Singleton counterparts, and can be swapped out for true instance classes without modifying any external code calling the class. Monostate also don't have quite as many multi-threading issues as Singleton classes, since there truly is no way to accidentally get multiple copies of the data with Monostate. A careless Singleton implementation could end up with several instances if called simultaneously from multiple threads. Both patterns require locking on their data members though.

One thing to also keep in mind when implementing a Singleton or Monostate pattern is that you want to make sure that you are using the pattern because the data requires that it not be copied in two places. If you are implementing Singleton because you want to save the cost of object instantiation, think again. If you are implementing either of them because it makes the logic more simple, then think again. The only reason to use these patterns is because your data dictates that it cannot be out of sync.

So, there you have it, hopefully another useful addition to your pattern tool belt. And like always, if you liked it, please kick it!

So, in my previous post about testing MVC controller actions with Moq I left out any way to verify the calls on my MockUserRepository class. I did this because I wanted to have one MockUserRepository that I used for all tests in the UserControllerTest test class (most would refer to it as a fixture, but visual studio test likes to be different). So I factored out a class that was cleverly called "CreateMockUserRepository". The original version of the method looks like this:

private Mock<IUserRepository> CreateMockUserRepository()

{

    var user = new User()

    {

        Id = 10,

        UserName = "TestUser",

        EmailAddress = "test@test.com",

        ModifiedOn = DateTime.Now,

        CreatedOn = DateTime.Now

    };

    var mockUserRepository = new Mock<IUserRepository>();

    mockUserRepository.Expect(ur => ur.GetUser(10))

        .Returns(user);

    mockUserRepository.Expect(ur => ur.SubmitChanges());

    return mockUserRepository;

}

This all worked fine and great, and if I called "VerifyAll" on my Mock<IUserRepository> then everything would work great. But what if I wanted to reuse this method for more tests. I wanted my mock to be useful in multiple places. So, lets say I changed it to look like this:

private Mock<IUserRepository> CreateMockUserRepository()

{

    var user = new User()

    {

        Id = 10,

        UserName = "TestUser",

        EmailAddress = "test@test.com",

        ModifiedOn = DateTime.Now,

        CreatedOn = DateTime.Now

    };

    var users = new List<User>() 

    { 

        new User() { Id = 10, UserName = "TestUser", 

                        EmailAddress = test@test.com, 

                        ModifiedOn = DateTime.Now,

                        CreatedOn = DateTime.Now },

        new User() { Id = 11, UserName = "TestUser2", 

                        EmailAddress = test2@test.com, 

                        ModifiedOn = DateTime.Now,

                        CreatedOn = DateTime.Now }

    };

    var mockUserRepository = new Mock<IUserRepository>();

    mockUserRepository.Expect(ur => ur.GetUser(10))

        .Returns(user);

    mockUserRepository.Expect(ur => ur.GetUsers())

        .Returns(users);

    mockUserRepository.Expect(ur => ur.SubmitChanges());            

    return mockUserRepository;

}

Here we have added a List<User> to hold multiple users for use with our "GetUsers" call. And at the bottom we set our expectation. So, this will now make my test for a single user edit fail. It will fail because we have setup an expectation on "GetUsers" that we never call. One solution would be to just not call "VerifyAll" knowing that my expectations aren't going to be met, but this is obviously not ideal. Another idea would be to just create my test data and setup expectations inside of each test. I'm not a fan of this either because I have more than a few methods that need to be setup and I'd rather not have to set them up in each and every test. A third option would be for me to just create an IUserRepository stub and just use my own state variables to check that certain methods had been called. I would also rather not do this because I don't see why I should mimic the behavior that my mocking framework already provides for me.

So what is a programmer to do?

Well, download the source and start futzing. I decided that my best course of action would be to somehow allow groups for "Verifiable" expectations. So, I figured that passing in a string was good enough for me now. I went into the Moq source and found that adding a parameter on the Verifiable and Verify methods was actually quite easy. I then copied my custom build over my old Moq dlls and I changed the last few lines in the above method to look like this:

var mockUserRepository = new Mock<IUserRepository>();

mockUserRepository.Expect(ur => ur.GetUser(10))

    .Returns(user).Verifiable("SingleUser");

mockUserRepository.Expect(ur => ur.GetUsers())

    .Returns(users).Verifiable("MultiUser");

mockUserRepository.Expect(ur => ur.SubmitChanges())

    .Verifiable();

You'll notice the "Verifiable" calls on the end of the "GetUser" and "GetUsers" now have string parameters where I am passing values into each of them. This add those verifications into that particular group. I could have multiple verifications in any of the groups. Then the "Verifiable" on "SubmitChanges" doesn't have any parameters so it acts just like it always has. The idea here is that now in my single user edit, I can now make this call:

mockUserRepository.Verify("SingleUser");

And only my "GetUser" and "SubmitChanges" verifications will be tested, my "MultiUser" verification will be ignored for this test. And that is it!

So, does anyone else think that this might be a good addition to Moq? Does anyone else have a better way that I could have implemented this? (I've been working with Moq for all of 3 days now, so I could be missing something elementary) If so, then please let me know. Otherwise I may pull down the latest dev source and work my changes into it, then submit a patch and see if those guys might work it into a future version.

I wanted to follow up my last post about Asp.net MVC controller testing to show you how I have shortened up my testing code quite a bit. I am putting this up to hopefully get some feedback, but also hopefully someone else will get some good ideas from it. I am using Moq in these examples, but obviously you can use your own mocking framework.

If you didn't see my last post about Asp.net MVC Controller testing, then you won't be able to appreciate this:

public void UserControllerUpdateTest()

{            

    IUserRepository mockUserRepository = CreateMockUserRepository();

    UserControllerForTesting mockController = 

      CreateMockUserController(mockUserRepository);            

    var mockContext = new MockHttpContextContainer();

    mockContext.FormData.Add("User.UserName", "TestUser2");

    mockContext.FormData.Add("User.EmailAddress", "test2@test.com");            

    mockController

      .SetFakeControllerContext(mockContext.GetHttpContext());            

    mockController.Update(10);

    Assert.AreEqual(mockController.RedirectedAction, "List");           

    Assert.IsNotNull(mockController.TestingViewData);

    MvcMockHelpers.VerifyFormData(

      mockController.TestingViewData.User, mockContext.FormData);                    

}

It is quite a bit shorter now than it was previously and I have abstracted out quite a bit into separate helper classes that I use for testing. There was also a little bit of completely unneeded code in my older test that I realized I had. So, to start simplifying the code a bit the first method I created was "CreateMockUserRepository". Right now it doesn't really do a whole lot except for return one user on a particular method. But it can be expanded later to do much more for more tests within this controller.

private IUserRepository CreateMockUserRepository()

{

    var user = new User()

    {

        Id = 10,

        UserName = "TestUser",

        EmailAddress = "test@test.com",

        ModifiedOn = DateTime.Now,

        CreatedOn = DateTime.Now

    };

    var mockUserRepository = new Mock<IUserRepository>();

    mockUserRepository.Expect(ur => ur.GetUser(10))

        .Returns(user);

    mockUserRepository.Expect(ur => ur.SubmitChanges());

    return mockUserRepository.Object;

}

In fact, it is likely that at some point I would just implement an entire IUserRepository stub that would implement all the methods and return dummy data. But for right now this is serving my needs. I like to only implement as much as I currently need in order to get my tests passing.

My next method is "CreateMockUserController" which I pass my mock IUserRepository into. The UserControllerForTesting class is then given a fake view engine, which I saw on this post by Derik Whittaker.

private UserControllerForTesting 

    CreateMockUserController(IUserRepository repository)

{

    UserControllerForTesting fakeController = 

      new UserControllerForTesting(repository);

    FakeViewEngine fakeView = new FakeViewEngine();

    fakeController.ViewEngine = fakeView;

    return fakeController;

}

In this method I am creating my UserControllerForTesting class which looks like this (the idea came from Phil Haack's post):

internal class UserControllerForTesting : UserController

{

    public string RedirectedAction { get; private set; }

    public string ViewRendered { get; private set; }

    public string MasterRendered { get; private set; }

    public UserControllerViewData TestingViewData

    {

        get

        {

            return (UserControllerViewData)typeof(UserController)

                .GetField("_viewData", BindingFlags.NonPublic | 

                  BindingFlags.Instance).GetValue(this);

        }

    }

    public UserControllerForTesting(IUserRepository repository)

        : base(repository)

    {

    }

    protected override void RedirectToAction

       (RouteValueDictionary values)

    {

        RedirectedAction = (string)values["Action"];

    }

    protected override void RenderView

        (string viewName, string masterName, object viewData)

    {

        ViewRendered = viewName;

        MasterRendered = masterName;

    }

}

Here I have overridden RedirectToAction and RenderView in order to expose what is being passed to these two methods. This obviously allows us to test which views were redirected to or rendered.

So now that I have my mock repository and mock controller with a fake view. I then created a class called MockHttpContextContainer. I created this class because just using the MockHttpContext from the MVC Helper classes didn't allow me to set more expectations on the classes that were referenced by the HttpContext. In my case I needed to be able to set a return value on the Form parameter in the HttpRequestBase class that contains the form data. Here is the MockHttpContextContainer class:

public class MockHttpContextContainer

{

    public Mock<HttpContextBase> Context { get; set; }

    public Mock<HttpRequestBase> Request { get; set; }

    public Mock<HttpResponseBase> Response { get; set; }

    public Mock<HttpSessionStateBase> SessionState { get; set; }

    public Mock<HttpServerUtilityBase> ServerUtility { get; set; }

    private NameValueCollection _formData;

    public NameValueCollection FormData

    {

        get

        {

            if (_formData == null)

            {

                _formData = new NameValueCollection();

                this.Request.Expect(r => r.Form).Returns(FormData);

            }

            return _formData;

        }

    }

    public MockHttpContextContainer()

    {

        Context = new Mock<HttpContextBase>();

        Request = new Mock<HttpRequestBase>();

        Response = new Mock<HttpResponseBase>();

        SessionState = new Mock<HttpSessionStateBase>();

        ServerUtility = new Mock<HttpServerUtilityBase>();

        Context.Expect(c => c.Request).Returns(Request.Object);

        Context.Expect(c => c.Response).Returns(Response.Object);

        Context.Expect(c => c.Session).Returns(SessionState.Object);

        Context.Expect(c => c.Server).Returns(ServerUtility.Object);

    }

    public HttpContextBase GetHttpContext()

    {

        return Context.Object;

    }        

}

As you can see here I am exposing all of the parts of my HttpContext object as Mock<T> objects which will allow me to setup expectations on them. I'll also be able to add helper methods/properties like I have here so I can easily setup things like FormData. I also put a method called GetHttpContext to return my actual HttpContextBase object so that I don't have to call mockContextContainer.Context.Object, it just makes it look a bit nicer. I like my code to look nice.

So, that explains about the first half of my UpdateUserControllerTest until we get to SetFakeControllerContext. This is also part of the MvcMockHelpers class that Scott Hanselman put up on this post. I believe I am using a custom overload, but it shouldn't be anything too crazy. It just looks like this:

public static void SetFakeControllerContext

    (this Controller controller, HttpContextBase httpContext)

{

    SetFakeControllerContext

        (controller, httpContext, new RouteData());

}

public static void SetFakeControllerContext

    (this Controller controller, 

     HttpContextBase httpContext, RouteData routeData)

{            

    ControllerContext context = new ControllerContext

        (new RequestContext(httpContext, routeData), controller);

    controller.ControllerContext = context;

}

Pretty simple. Now everything is setup, finally! Now all we have to do is call our Update method on our controller class. We pass in id 10, as we have currently setup our expectations on this. We obviously didn't have to specify 10, and we just as easily could have setup our expectation to accept any integer, this is how you do this in Moq:

mockUserRepository

    .Expect(ur => ur.GetUser(It.IsAny<int>())).Returns(user);

Then what is left is to test our state. We first test "mockController.RedirectedAction" to see if it was redirected to "List" because this is what our controller method does. We then check to make sure our view data is not null and then we pass our view data user object and our view data into a method that I created called "VerifyFormData". This method basically does the same thing as "BindingHelperExtensions.UpdateFrom" in that it takes our User object and our FormData object and loops through to make sure that the user was updated with all of our form values. It looks like this:

public static void 

    VerifyFormData(Object data, NameValueCollection values)

{

    Assert.IsNotNull(data);

    Type dataType = data.GetType();

    string dataName = dataType.Name;

    int comparisonCount = 0;

    PropertyInfo[] properties = dataType.GetProperties();

    foreach (PropertyInfo property in properties)

    {

        string key = dataName + "." + property.Name;

        if (values[key] != null)

        {

            comparisonCount++;

            object value = property.GetValue(data, null);

            TypeConverter conv = 

                TypeDescriptor.GetConverter(property.PropertyType);

            object formDataValue = values[key];

            if (conv.CanConvertFrom(typeof(string)))

            {

                try

                {

                    object convertedValue = 

                        conv.ConvertFrom(formDataValue);

                    Assert.AreEqual(convertedValue, value);

                }

                catch (FormatException)

                {

                    Assert.Fail

                        ("Format Exception Property: " + key);

                }

            }

        }

    }

    Assert.AreEqual(values.Count, comparisonCount);

}

We just loop through our properties and pull the data from our FormData. We then check to see if we used all of our form data by comparing counts. This may or may not be necessary in the future. I have yet to decide if this will get left in.

Well, for this controller method these tests are pretty good with one exception. I wanted to test to make sure that my proper method was called on my repository and I wanted to check to make sure that SubmitChanges was called on the data context. Normally we could call "mockUserRepository.VerifyAll" but this would fail to work if we expanded out our repository to have more than just the two expectations. This is because we would be setting up expectations on a bunch of different methods. I haven't quite figured out yet which direction I am going to go with this, but I will blog about it when I do. If anyone has any ideas, please let me know.

Let me first start off by saying that I love Linq. I think that idea of injecting set based logic as a language feature is genius. I believe that we will start to see even more advantages of this when we start doing more parallel programming. But right now Linq has the ability to simplify a lot of code that we have to write in order to filter and manipulate in-memory classes. So what would be better than to apply this directly to a database? Well...nothing. The ability to have strongly typed queries that can persist data into POCOs is actually a pretty appealing proposition, so what is wrong?

Well, I was trying to do a very simple setup that is quite common among business application developers. I was trying to create a business entity base object that all of my business objects descend from. In this instance I have created a simple scenario that looks like this:

In this instance the BusinessBase would have any common properties like "Id" or a property like "LastUpdated" which tracks the last insertion in the database. Usually this class will also contain any methods that you don't want duplicated across all of your business objects. So, you would think that this kind of setup would be quite easy for Linq to Sql, but it isn't. Linq to Sql only has one concept of inheritance, and that is table inheritance. Table inheritance is if you had a class heirarchy that looks like this:

Then all of these classes would be stored in a single table with a column called something like VehicleType. Then you could query out a Truck and LinqToSql could look for only that type by using the VehicleType column. This type of inheritance is very useful for mapping to tables, but what about the inheritance that I showed earlier where it has no effect on the table mapping? This is where we start to have trouble.

Now, if you want to use the Linq To Sql designer plugin for Visual Studio then you should probably stop now. The designer for Linq To Sql (as well as SqlMetal) have a few limitations that get you right off the bat. Number one for me was not having the ability to put classes in separate namespaces, all of the classes that are generated have to be put into the same namespace. I don't know about you, but this doesn't really fly for me. Secondly, there really is no way to have your own business object hierarchy since that would require modifying the generated file and you would just overwrite it anytime you made a modification. Not really ideal. So I decided that I would have to bite the bullet and do manual mappings, which ended up not being too hard thanks to SqlMetal.

First of all I prefer to use Linq To Sql with map files, I don't like having the attributes spread all throughout my application. I'm not really religious about which way to do it, but I prefer to have a single map file where I can go to view all of my mappings. I used SqlMetal to generate my initial mappings, and then I can tweak them. To do this I just open up the Visual Studio 2008 command prompt and run this command: (you'll need to modify it for your settings, it requires you to spit out a code file as well, but you can use this as a starting point for your datalayer classes)

sqlmetal /server:. /database:DatalayerTest /map:"Map.map" /code:"Map.cs"

So, my mapping for my User class looks like this:

  <Table Name="dbo.Users" Member="Users">

    <Type Name="Core.Membership.User">

      <Column Name="Id" Member="Id" 

              Storage="_Id" 

              DbType="Int NOT NULL" IsPrimaryKey="true" />

      <Column Name="Username" Member="Username" 

              Storage="_Username" 

              DbType="NVarChar(100) NOT NULL" CanBeNull="false" />

      <Column Name="EmailAddress" Member="EmailAddress" 

              Storage="_EmailAddress" 

              DbType="NVarChar(255) NOT NULL" CanBeNull="false" />

      <Column Name="Password" Member="Password" Storage="_Password" 

              DbType="NVarChar(255) NOT NULL" CanBeNull="false" />

      <Column Name="LastUpdated" Member="LastUpdated" 

              Storage="_LastUpdated" 

              DbType="DateTime NOT NULL" />

      <Association Name="FK_Orders_Users" Member="Orders" 

                  Storage="_Orders" 

                  ThisKey="Id" OtherKey="UserId" 

                  DeleteRule="NO ACTION" />

    </Type>

  </Table>

In this map the "Id" and "LastUpdated" columns are located in the Core.BusinessBase while the rest of the columns are located in the Core.Membership.User class. With this exact mapping and the setup I just described you will get an error that says this:

"The column or association 'Id' in the mapping had no corresponding member in type 'User'. Mapping members from above root type is not supported."

Doh! So, essentially what this is telling us is that Linq To Sql cannot see properties that are in the hierarchy of the class that we are currently using. So, how do we fix this? Well, we introduce wrappers for our properties that we have in the base class. Booooooooooooooooooo! This means that every property we have in our inheritance hierarchy that we want to expose through our entity we have to write wrappers for them. Now, I can understand for performance reasons why they wouldn't want to look through a large inheritance hierarchy for these properties, but I think that we should at least have this option (especially if we know our hierarchies aren't that deep).

private new int Id

{

    get { return base.Id; }

    set { base.Id = value; }

}

private new System.DateTime LastUpdated

{

    get { return base.LastUpdated; }

    set { base.LastUpdated = value; }

}

So, what happens when we put these wrappers classes in place? It all works, right? Nope. As soon as we put these wrappers in place we get this error:

"Bad Storage property: '_Id' on member 'Core.Membership.User.Id'."

If you look back at the Xml mapping up above you will see there is a "Storage" attributes on each Column element. This is actually optional, but you use it to tell Linq To Sql which private variables to use to store values. This is quite important if you have business logic that runs when an item is assigned to a property and you want Linq To Sql to bypass the property when creating a class. In our base class our fields look like this:

private int _Id;

private System.DateTime _LastUpdated;

The problem is that Linq To Sql cannot see these variables when it reflects over our class, a quick fix it to make them protected and voila, suddenly Linq to Sql can now get to them! This issue isn't quite as big of a deal as having to paste wrappers throughout all of our business objects, but sometimes the error above doesn't quite point to exactly what the problem is.

So, this isn't that big of a deal, right? Well, pasting wrappers across a large number of business objects could be considered a pretty big deal, but overall it isn't terrible. At least you are able to have POCO support, even if it is not perfect. So, what did they do right with Linq To Sql?

1) Actual POCO support, not the IPOCO (come on!) stuff that the Linq To Entity people are pushing.

2) I don't have to have a public constructor, Linq To Sql will find a private parameterless constructor. This way all of my business classes can be created through a factory method, but it would have been cool if there was support for factory methods in the mapping. Although they were probably trying to keep things as simple as possible for v1.

3) They give you the option of supporting interfaces for property changes, but they aren't required (these are INotifyPropertyChanging and INotifyPropertyChanged).

4) Even though my business classes can't be in different namespaces with the Linq To Sql designer, I can do this using my POCO classes.

5) SqlMetal allows me to automatically generate my map files and my classes which allow me to have a starting point for my business classes.

Linq To Sql is not perfect, and yes I know that it isn't the only OR/M solution out there, but they have done an excellent job in v1 and hopefully we will get a bit more flexibility in v2. In the meantime these are some pretty simple solutions that you can use to wrangle Linq to Sql into your datalayer. Also, if you have any good ideas for how to do any of this better please let me know!

Click here to download the full source for the Linq To Sql datalayer - This is not production code, it is barely even test code. I am providing this because if I don't someone will complain, so please don't make any comments about it.

How come in a world of powerful languages, IDEs with intellisense, O/R mappers, unit tests, numerous libraries, copious amounts of third party tools, continuous integration, tons of code samples, thousands of developer forums, and more technical books than you can shake a stick at, is it so freakin hard to produce good software?

There is a blog post by Oliver Steele that has gotten some recent attention (despite the fact that it was written in 2004!) and it is called "The IDE Divide". In this post Oliver Steele talks about a divide in the programming world between what he calls the "language mavens" and the "tool mavens". He points out that people are often either big proponents of a particular high level language, or group of high level languages (an example he uses is Haskell), or they put tools above languages and focus more on how much more productive tools can make them. While I don't have any fundamental problems with his post (it does actually make several good points and draws several important conclusions), I think it does underscore a particular mindset that often occurs in software development where we see tools and languages not problems and solutions. If something goes wrong, then we need a tool to fix it! If this project failed, well if we had been using language X or tool Y then it would have been easier! We often want to put the implementation above the problem.

I think we do this for several reasons. (keep in mind that in this list the word "customer" is overloaded, a customer is anyone who is consuming your software)

1. It's the fun part! For most of us we started off hacking away at software in our younger years before we ever knew what specs or customers were. Because of this, and because the fact that most of us just want to write code, we often enjoy the architecture/design/development part of the software more than the requirements gathering. Go figure. This can be a good thing, if we didn't enjoy the construction part then all of our jobs would be hell, but at the same time, you need to figure out what you are going to build before you build it. As Alan Stevens put it in a recent tweet "Knowing what to build is the hardest part. Everyone focuses on the how to build it part because that's an easier discussion." And he is completely correct, discussing construction is more natural for us because that is what we like to do and that is what most of us were trained to do. How many blog posts have you seen on requirements gathering?
2. We think we already know what needs to be written. By the time that most programmers hear about a new piece of software that needs to be written they are already designing it in their head. Once we start thinking about it we start building up layer upon layer of preconceived notions about what we are going to be building. I can't tell you the number of times that a project has been put in front of me that needs a quote and I see the customers initial request and start thinking about what we would have to do in order to build such a system. Then when you start asking the customer questions about what needs to be built you realize that the system is nothing at all like you would have envisioned. There is either a barrier of language, lexicon, or experience between you and the customer.
3. A lot of methodologies at first glance support this behavior. A lot of people will take the parts of agile development that they want and throw the rest out. They will latch onto the parts about not having a big spec up front and writing tests first and think that this means that they should just jump right in and let the application evolve. Well, that is a great idea as long as you want crappy software. Even in most agile methodologies there is a strong emphasis on gathering requirements and defining things like user stories up front so that you *know* what you are building before you build it. You may not know exactly *how* you are going to build it, but you have a general idea of *what* you are building.
4. This is what a lot of us are used to. There are *a lot* of development shops out there that still writing software as if the developers are operating in a vacuum. A team of people will hammer out a detailed spec (assuming you have a spec) and then they will "throw it over the wall" and the development team will disappear to their cubes for 3 months and then out pops a grotesque conglomeration of specification and assumption. Then they get a long "you screwed this up list" and go back and start the same process to get the software to do what the customers actually wanted, the only problem is that they are using the same system that screwed it up in the first place. Look ma, no collaboration!
5. We aren't agile. We think that specs and requirements are something that you only get before you build software. How many times have you completed a task only to show a customer your proud accomplishment and you receive a list of things that are completely wrong with your design? You may have heard the term "impedance mismatch" when talking about ORM software, well this is impedance mismatch for requirements. Your customers requirements go in one end and then there needs to be a translation layer into your requirements. This translation is neither clean nor is it deterministic. Another point, you need to have customer feedback. At at a previous job I held I was given a project and the specs weren't very clear at all. I asked my boss to allow me to go talk with the people that were using the software and he told me that I didn't want to do that because it would just start down a road of constant changes and requests! There are two problems here, first you need to set customer expectations. They should not have the idea that every little tweak or suggestion they have is going to get implemented, but writing an application for someone without feedback is a lot like throwing javelin with a blindfold. Secondly, to assume that changes are bad is how you end up with bad software. Software needs to evolve in order to meet business requirements.
6. Your specifications are not very specific. You look at your specs, you see a lot of holes, and so you want to just fill them. Having a lot of gaps to a certain extent is a good thing! Your customer often doesn't know what they want any more than you do. The only way to get it right is to evolve both of your opinions in the process by delivering early and often. This way your customer can start to get a clearer picture of how they want the system to work while you start to see the evolution of the customer's decisions which will make it easier for you to predict their needs. To paraphrase Steve McConnell if your customers specifications spelled out the software 100% you'd be better off just executing the spec. Keep in mind also that good specs tell you what needs to happen (and may give a little guidance on how), bad specs tell you in detail how to do it.

You might be thinking right now "So, you are saying that I should put the spec first? We just don't have time to hammer out a big spec before (or during) our software development!" Well, I'm not telling you to make a big spec document. I think that big spec documents are something that hurts software development, not helps it. I'm not even necessarily saying that you should follow a formal agile methodology, what I am saying is that you *need* to take the time to figure out what you are going to write. You need to figure out what problem you are solving or what task you are trying to accomplish. You need to talk with your customer and figure out what they need from the system and what pain they are having that needs to be alleviated. Whether you put it on note cards, a white board, or in a word doc, you need to figure out what you are going to do.

So, why do good programmers who use all the tools at their disposal write bad software? Because we aren't writing the correct program and we aren't solving the right problem. We aren't going to our customer and getting feedback and we aren't keeping up with changing requirements. Most often this is because we don't know what our requirements are. Generally speaking, our customers are not experts in application design, and usually they don't understand how to give you requirements. The only process they have for giving you requirements can be to look at an application and tell you what is or is not correct. By acknowledging that the software you are writing is only partially correct, you will mentally prepare yourself for the inevitable changes that will come down the pipeline.

So, just remember that you can use BDD, TDD, DDD, MVC, ORM, (enough?) all you want, but if you are not writing what your customer wants and needs then you are just wasting time. So the next time someone tells you not to do something because it may result in change requests just tell them "we aren't writing software because we have a bunch of hard drive space that needs to be filled, we are writing software to solve problems and unless we are solving the right problems we might as well just stop writing code right now."

...stepping down from soapbox.