Client: So you have heard the idea, now what I need to know is how much is this going to cost?

Me: I have absolutely no idea.

Client: Ok…then can we talk with someone else at Coshx, maybe someone that actually knows how to code?

Me: They don’t know either. They will just look at me like I’m crazy and should know better.

Client looks at me like I am crazy and should know better

Client: Um, look….we like you guys, and we want to work with you. We know what we need to build, so can you just tell me how much it will cost so we can get started and pay you?

Me: No. And now that you bring it up, you actually have no idea what you need to build, so stop being ridiculous so we can get to work figuring it out.

I remember when I was on the other side of this conversation. As an MBA candidate with a background in private equity and real estate my inclination was to plan, analyze, and plan some more. This makes a lot of sense when you are building a new apartment building. Look at economic and demographic trends, figure out what class of building is in demand, analyze prices for various materials and other costs and plop your data into a model. Run this against various scenarios and revenue projections and figure out what mix of units, amenities and other features give you the best return on investment (technically we look more at IRR, but let’s use ROI of simplicity). Hire a firm to produce exact specs and a contractor to hold to them as dearly as possible. Rinse and repeat.

This mindset can make it hard to begin a software project. There is a direct and negative correlation between someone’s level of experience in another field of business and their initial comfort with our development methodologies. I can assure you that our approach is solid, proven, and derived from a combination of accepted best practices and our experience delivering applications to clients who soon realize that we are not insane. Or, at the very least, that we are competent and rational human beings that only dabble in insanity and that software development is a very different game than building a skyscraper.

To begin with, most of our clients are trying to build something inherently new and novel. Otherwise, why would they build it? Unlike housing, which has been around basically forever, the mainstream web is still an incredibly young and maturing organism and we are still learning about how people interact with it. If you don’t believe me then think about the fact that Derek Jeter was playing for the Yankees while America Online was still charging for internet by the hour. Couple this with the fact that product development should be an iterative process regardless of your medium and you begin to understand why too much requirement planning results in poorly built software. The code (how you built it) may be solid, but the product (what you built) is probably full of useless features that no one uses but someone paid for.

This is not to say that our approach is not disciplined or that there is not an large amount of planning, we simply build agility into our planning. We plan for the unexpected and expect that requirements will change throughout the course of development. We whittle your application down to fundamental features that provide the core value you intend to deliver to your users and then let them use it. That expensive feature you wanted to build but we gently told you not to? Maybe no one cares about it. The other feature that 60% of your test group wants to see added? Maybe it was never discussed in our planning meeting two months before, but since we planned for the unexpected we can incorporate this feedback into our next iteration. That is the fun of software. Unlike apartment buildings you can rip out features and your building will not collapse and you can add new ones without having to redo all the plumbing.

The point of all this is simple: create the best possible product and maximize your ROI one sprint, one feature, and one user story at a time. In another post I will explain what the hell that means and why our inability to give you an estimate is not due to our incompetency but our desire to build you the best application possible.