On the product end of things a fixed price makes a lot of sense. Squeejee builds custom web applications...billing hourly for that is a no brainer.
Much of everything else is a hybrid. I would expect that I could get a reasonably accurate estimate for painting my house based on the experience of a painter. With a fixed set of requirements and a familiar problem domain, I would think Squeejee could do the same.
I think the major point was that, yes an experience developer can make a good accurate quote, but it needs the requirements to be nailed down and in fine detail before that quote really means anything. Being that most clients probably don't know what they want until they see it, accurate requirements are hard to find.
More common these days are some user stories and lots of rapid iterations until the client is happy I guess.
The house painting analogy fails because in software development, you only have a vague idea of how big the "house" is.
No painter would give an estimate for painting a house, sight unseen, with only vague descriptors. But yet that's exactly what fixed-bid contracting is for software development.
Clearly the house painting analogy fails. All analogies do. My point was that the two extremes are fixed-bid and hourly.
For the sake of a client, a programmer with some expertise should be able to give a reasonable estimate based on a set of requirements.
I would say your house painter analogy fails as well. Fixed-bid contracting for software development is nothing like painting a house sight unseen, with only vague descriptors. Analogies aren't really the point though...
One of the most harmful results of fixed-bid contracting is that it gives offshore developers a huge advantage. It'll take them three times as long and they'll ship a worse product, but the "shipped" cost will still be lower. You don't see the hidden costs like maintainability and poor code quality until afterwards.
Absolutely true. The advantage is the same regardless of billing model.
I've found you can't compete against off-shore outfits on price if you want to keep making money. So don't even try. Your competitive advantage is quality, communication, and responsibility.
You can deliver high quality product, designed for extension/enhancement in the future, and can communicate clearly with the client, and understand what they want (without them having to create a 50 page requirements document covering every tiny detail), and after the delivery they can call you up, and speak to the same person they talked to before, on the phone, and you'll take personal responsibility and pride in your deliverable. That costs more. End of story.
You won't get every client, but trust me, the ones that just care about the lowest $ figure above all else, aren't the clients you want to have anyway.
I'm not sure it is. When someone asks for a large, but reasonable rate, like $75 or $100 an hour, you generally know that they're good at what they do, and that they're worth the cost.
There's kind of a sweet spot in there- less than $35 an hour, you know they're amateur and you feel like you're getting substandard service. Much more than $100 an hour and you know you're getting fleeced.
All of my current client projects are hourly. I typically give them an estimate so they have a ball park figure and then bill hourly and update them as the project progresses. This seems to work out really well.
The only downside that I see so far is that as you get better as what you do you tend to get quicker as well, which in an hourly arrangement means you make less. You can always raise your rates as your experience grows but for previous clients it can be hard to explain.
Sure it does, but if you're working hourly, you're still making the same total $, working the same hours, just over more projects.
For me, while I do love coding, my side projects truly are a means to an end ($$ to put in a home theater, or take a trip, or do whatever else I want to do).
Hidden in your question is the kernel of why fixed-bid is better when your skills (in terms of lower hours-expended for a finished-system) are better than your competition, and you can sell it.
Now, all that said, I'm wrapping up a fixed-bid (~$25K) side project where scope creep is killing me on my (effective) hourly rate. It's still fun; I'm learning a lot about things I don't do in my "day job" and I'm almost certainly going to get more work from this client if I want it, but I made the mistake of bidding fixed-price with some assumptions about the scope that were ludicrously off. (My fault, not the client's, and I'm eating it. If the work weren't fun, it would be an extremely bitter taste...)
I'm still in favor of the fixed-bid (as it makes the sales job much easier), but watch scope creep.
One last important point: if you are bidding fixed because you are a great coder and a poor salesman, your lack of sales/negotiation skills may be an issue when the client thinks something was in scope and you think it's out of scope. If this is a possibility, figure out your strategy ahead of time, or you'll end up doing the feature "for free".
That's the main reason why languages like C++ and Java are so popular. Getting paid for amount of time or amount of code makes succinct and simple solutions less interesting for developer.
As we all know, succinctness = power. Everybody lose in the long run when developers are not motivated to solve the problem in less time with less code and as simple as possible.
I'm amazed that some people treat it as something "so basic".
Did you just say that the reason C++ and Java are popular is developers don't want to spend clients money writing everything from scratch (in what? assembler? fortran? C?) in the most simplified way possible?
I don't even know where to start with that. Using existing code libraries for common tasks means less development time/cost, higher quality code (the code has been tested by thousands of people over months or years), and easier enhancement/extension in the future (the code already solves for many common enhancements and/or is built in a modular/configurable/etc... manner and so on).
Writing your own "super-awesome-optimized-magic" ORM/Internationalization/Transaction Management/Caching/Encryption/MVC framework/XML parser/etc... is generally a bad idea for you and your client.
No, I just say that getting paid for amount of time motivates developers to write complex and bloated code in complex and bloated languages. There was nothing about "writing from scratch" or libraries available.
Example: client wants new feature -- if my language and my platform let me do it in one line of code it's bad for me if I get paid for time, thus people choose languages and platforms where even trivial things can be written with some bloat.
Though the customer may be afraid that the developer can just start piling hours without real productive work. Still, I think the customer has the possibility of asking for a replacement of the consultants if he does not see good results. Later on in the project may be harder but still possible.
Billing by the hour may be way too granular for some projects. Contractors should also consider day-rates. It can be a good compromise between hourly billing and fixed bids.
I'm in favor of T&M (Time and Materials) work for software development, simply because the universe of solutions is so broad.
Having said that, the argument put forward in this article is nowhere near complete. Yes, when you're getting paid by the hour the client has his foot on the gas pedal, but in reality he's already sunk a big hunk of money on you, from his standpoint on a long project it can easily look like throwing good money after bad.
Yes, agile techniques make clients happy faster. But it all depends on where the risk is. And there is a difference between the client and the users. If the users have a hard time making up their mind what they want? Then the software process becomes part of a business decision support system. The team interviews multiple stakeholders and facilitates negotiation and conflict resolution.
You might say "that's not software work," but that's the real world with real humans in it. In that case, it could be easy for the client to see bills every week or two for what he thinks is just a lot of talking, From his standpoint, he just wants the coding done -- and of course the users should be happy. (grin)
Because it is so complex hourly is the most straightforward way of working. I've been watching this scene for many years, though, and I have the sneaking suspicion that fixed price bids are what separate the men from the boys when it comes to delivering technology solutions -- mainly because the profitability can swing wildly from rolling-in-the-bucks to sucking-wind.
One way to screw hourly billing: you feel compromised to stay in a project until it's closed, but the project hasn't a close date, so it might never be properly closed. But you might actually want to get out of it to do some other interesting or more expensive work, and if your client feels like it, he/she might never really free you from your project. That's one danger of hourly billing for hourly beginners.
My first "pro" hourly gig ended up going week-to-week with no end in sight. We were doing a great job, but the VP who was paying us was fighting with another VP over who owned the program. After 2 months I had enough and left. A year later the team was still there.
Fixed bids aren't so bad. The trick is learning to do really good estimates. Figure out how much information/requirements you need in order to create an estimate, and get that data first. Document what YOU understand the scope of work to be (separately from the provided requirements) and make that the basis for your fixed bid.
Many customers will prefer a higher priced fixed bid, rather than a lower prices hourly based estimate, because they can budget for it (or get budget for it) without worrying about overruns. Many less scrupulous development firms (or people who just can't estimate very well) end up billing well over the initial estimate when doing hourly invoicing, and many customers have been bitten by that before.
In my experience smaller client will be more likely to go for the hourly approach, due to the initial estimate being lower, and feeling like they have more control over the costs during the course of the project. Larger companies almost always work with fixed size budgets approved on a project by project basis, and so having a fixed cost (even if it's potentially higher) is key for their internal budgeting and resourcing. Plus it protects against the overruns hourly project can bring. I've never seen a Fortune 500 outsource a full development project on an hourly basis. It's almost ALWAYS fixed price, just due to how they handle their own budgets.
The trick, imho, to good fixed price cost estimating is to get the best requirements you can up-front, and restate them yourself in your SOW, broken out by task groupings instead of however the client structured them. Clarify any potentially nebulous requirements/tasks yourself, and let the client know if they want to change the way you've filled in the gaps, they can do so, but you will need to submit an addendum to the invoice for any changes they make (unless otherwise agreed upon - i.e. same effort swaps of un-developed areas). Once you have the overall task list figured out, do your internal task breakdown and estimates. Then, pad your estimates out by perhaps 50% (this depends on how good you are at estimating, and how many times you've done task/feature X before).
If I have a task doing something that I haven't done before (i.e. some sort of crazy-cool ajax front-end wizardry (I'm a back-end guy)), I'll pad that out a bit more, since I'm likely to run into a snag or two along the way. If it's something I've done 100 times before (i.e. user registration/login/logout/forgot password flows), I don't need to pad that, since I can estimate that pretty exactly.
Also, don't worry if your padding seems high, or your SOW price seems too high. The client always has the option of doing an hourly approach instead. It's up to them. The more projects like this you do, the better you'll get at estimating, and it becomes second nature.
On the product end of things a fixed price makes a lot of sense. Squeejee builds custom web applications...billing hourly for that is a no brainer.
Much of everything else is a hybrid. I would expect that I could get a reasonably accurate estimate for painting my house based on the experience of a painter. With a fixed set of requirements and a familiar problem domain, I would think Squeejee could do the same.