Originally posted at 11/19/2010

I am writing this post from the point of view of the one you might have to ask forgiveness from, not the one who has to ask forgiveness.

There are two common styles of building software, one of them is Bold Exploration, and the second is Detailed Survey.

Bold Exploration have a rough idea about what is required, and immediately set out to build something that matches the current understanding. Along the way, both the team and the client will continually triangulate toward where they want to be. This is in effect the old “I’ll know it when I see it”. The problem from the point of view of the client (as in, me), is that I might be required to pay for those mistakes. For the most part, I don’t mind too much. One of the best aspects of this approach is that the time to get a feature in my hands is very short. I had a few memorable cases where it took the team three or four days to get something out that I could immediately comment on. There is another very important aspect. For the most part, this approach means that from my perspective, this is fire & forget. The way that I handle such things is usually by just having a phone call or two with the team, and then just getting their output and going over that, correcting the course if needed.

There were several times that mistakes where made, either because I didn’t explain right, a difference in vision or just simply because the team didn’t do things the way I wanted to. I asked for those to be fixed, and since we were operating on short time frames anyway, it didn’t cost too much (and I paid for both the mistake and the fixing of it).

Detail Survey involves the same initial phone calls, but then the team goes away to plan, estimate and build a plan for building the project. They are very careful about the way that they are going about doing things, and get back to me multiple times asking for clarification for this or that. When they start building the project, they start by building the foundations, getting things to work from the bottom up.  In many aspects, this is a very reasonable way to build software, expect for one very big problem. There is a long lead time until I get something that I can actually something with.

More importantly, this is me you are talking about, I am perfectly capable of looking at the code produce and estimate what they are doing. But, as impressive as a design is, it isn’t really interesting to me at all. I want to see the end features. And this approach takes a long time until I have something that I can actually work with.

I experienced both options recently, and I have to say that my preference is strongly toward the first approach. If pressed, I could give you a whole lot of reasons why I want that, valid business reasons, enough to convince any CTO or CFO. But mostly, it is an issue of matching expectations. When someone goes off for a month or two to do stuff, I get very nervous. And if you start building from the bottom up, it gets progressively harder to truly evaluate what is going on. When you get a working feature in the first week, even if additional work would cause rewrites/changes to this feature, you can be much more confident that this is going somewhere you want.

The other side is that no matter how careful the team is, there are still going to be differences between the final product and what I want, so changes will be made, but it is far more likely that with the Detailed Survey team aren’t used to those changes, and they are going to be harder to make.

In short, it all comes back to the fact that the shorter the feedback cycle is, the more happy I am.