People are a little weird when they’re starting a software project. They will talk about what they want it to do for hours. They will write documents about it. Schedule meetings about it.
They will never tell you how much money they have. That’s the part you’re supposed to guess.
I think this is weird. You write six pages of features, but not one line of “we’re thinking around $30k”.
Here’s why this happens: an old tenet of negotiation is “the first person to say a number loses.” Suppose you’re negotiating on the price of a bike. If you’re willing to buy the bike for $100, and the seller would be happy to part for it for $50, it makes a lot of sense for each person to try to make the other party say a number first.
The problem is that custom software is not like a bike in the garage. It’s more like a brand new bike concept you’re designing. You’re not negotiating on price, you’re negotiating on product. You have a list of things that you want–for it to have a jet engine and be able to fly at speeds of over 2,000 miles per hour–but the actual design of the bike is going to be constrained by your budget. Your bike would be a lot lighter and more reliable with a titanium frame, but this is terribly expensive. A carbon fiber frame might give you a lot of the benefit for some of the money, but if the budget is too tight, we can’t afford it either. With a cheap steel frame, the design will have to compensate with a beefier engine instead, leading to complicated maintenance and decreased reliability and energy efficiency.
One of these things costs more than the other.
This is the kind of call that software developers make when they try to estimate your project. Can we give up a little reliability in order to be more confident about the schedule? Can we increase maintenance costs in order to deliver every feature on the list? Do we have enough time to design something that will be easy to extend later, or are we in a rush and must we build something that cannot be easily modified? The job of a software developer is making tradeoffs to deliver a project within constraints.
The problem is that if you don’t specify a budget, then the budget is unconstrained. If you can think back to high school physics, you remember a lot of problems like “Consider a perfectly flat ball”, or “Consider a frictionless surface.” Engineers are trained to deal with unconstrained things by ignoring them. Your list of features reads like this physics problem: “Consider an infinite budget. Design a bike that has a jet engine…” And what you will get back from the engineer is a completely unaffordable bike design.
The very best engineers have been doing this long enough that they no longer consider infinite budgets. Instead, they will try to guess what your budget is, and design to that constraint. The problem is that it is very easy to guess wrong. Software budgets vary wildly– from $100 to hundreds of billions. If they close their eyes and pick $10,000 or $100,000 or $1m as your budget, they are still only going to guess right once in awhile. The very best engineers might be able to guess within a factor of three. That’s still a very good chance that they will guess wrong.
When you don’t reveal your budget, you waste everybody’s time. The engineers are out designing a rocket ship, when you need to ride downtown. They’re building a unicycle when you’re trying to get to outer space. You go to meeting after meeting, only to be disappointed with the proposal. If you finally get a document you like, it’s pure luck that they guessed right.
The key to building successful software is finding a software developer that you can trust to help you design your product within constraints. If you conduct an adversarial negotiation where you don’t share critical budget information with the people who are trying to make decisions on your behalf, the only way it can end is poorly. To create a successful project, you need to be on the same page, with everyone understanding what a successful software proposal looks like, and working together to communicate about tradeoffs in time, cost, and reliability.
Want me to build your app / consult for your company / speak at your event? Good news! I'm an iOS developer for hire.
Like this post? Contribute to the coffee fund so I can write more like it.
Comments
Comments are closed.
Tags 
- Subscribe via e-mail
Do you think that software development suffers more from this information exchange impasse than other contract work because many clients lack the technical training to understand software development? It must be hard to know how much one should pay for magic.
I think that happens whenever the contractor knows more than you, which is a common case for contracting, not just software.
I think a better way to frame the issue is that ordinary people have opinions about how Microsoft Office works but not, say, about how Ibuprofen works, which are both products produced by technical contracting. The result is a lot of armchair SJ wannabes that “know” what things “should” cost.