What We Won't Fixed Bid
Integration Projects
Unless we've done a specific integration before, we really have no idea how long it'll take, how many wrinkles will come up, how helpful tech support will be, whether the API docs are accurate, how many special error cases we'll need to handle, etc. Anyone out there comfortable with fixed bidding integration with systems you've never integrated with before? If so, how do you come up with the estimate and how accurate are they?
Reverse Engineering
If someone gives us a system and says "we want you to replicate this", we will never provide a fixed bid for that. We will do a free (possibly followed by a paid) discovery and will document what the system appears to do and we will provide a fixed bid for creating a system that meets the specs we documented from the system, but we'll never guarantee that our project will do what the original system did (how can you ever know for sure) - we'll simply use it as a starting point to work up specs and then agree to deliver anything that meets those documented specs. Do you do anything different? If so, how?!
Upgrades to Other Peoples Code
Every once in a while, someone comes to us with an app written in ColdFusion, PHP, C#, Java or whatever and says "I just need you to add xxx to this - what will it cost". We invariably answer that we have no idea but would be willing to put in an agreed number of hours and to see what happens. In my experience it is the smallest, simplest changes that usually kill you. You "just" need to add a field to a form, find the same place in the processing code, pass the additional value to the notification system to put into an email, and add it to the database and reporting. But of course somewhere along the lines you find that the system wasn't designed to handle long text or has problems with character encoding or when you set it to allow image uploads it breaks some other part of the form, or the tweak to the controller code breaks another form on another page that happens to reuse the same controller script but doesn't need the additional field. I have never found a way to accurately estimate what it would take to make even the smallest tweak to someone elses code. Sometimes it's an hour, sometimes it's 100, sometimes it would be quicker to re-write. Anyone have a different experience to this? Any hints to share?!
Performance Requirements
I have really mixed feelings about non-functional requirements such as performance requirements. I fully understand that an app may have valid non-functional requirements and that they could be important to the business case, but personally I have never yet provided a fixed bid for projects with performance requirements. The reason is that to me, such apps are "lab experiments". You build them, instrument them and then test them (I can fixed bid the build and maybe add 20-30% for the instrumenting), but then the problems start. If the project meets the requirements first time, you're all set. If not, you need to identify the bottleneck, speed it up, re-test, and then rinse and repeat until (hopefully) the app eventually meets the requirements. Depending on the app and the requirements, you might just need to remove an n+1 query (shouldn't really have been there in the first place), add a caching layer, write some stored procedures, or move the entire app (or parts of it) to a more performant language. It isn't impossible that you'll do all of the above and *still* not meet the requirements for a given hardware configuration and test setup. I just can't see how it would be possible to come up with a reasonable fixed bid that would cover this. Does anyone provide fixed bids for projects that include non-trivial performance requirements? If so, how do you estimate what the effort required would be?
Do you provide fixed bids for any of the above items? If so, how do you price them? Have you come across any other types of work that you wouldm't fixed bid? What and why? Input appreciated!



@Peter:
Amen to these. I've been faced many times with both the Integration project and the Upgrades to Others' Code project, and they are lose-lose situations, at least for fixed bid.
For Integration projects, I find that they can be a lot of fun, it's interesting to learn someone's API, to get that insight into how they constructed their app, but until you've actually consumed the API and made your app dance to the tune of the user requirements, it's really not possible to guess the level of effort. "Just gimme a ballpark" really doesn't cut it; that's how income fails to exceed overhead.
And when it comes to Upgrades to Others' Code, the few times I agreed to take these on (at any level) were a nightmare. After my first 3 years or so in the custom software biz, I simply refused to entertain the projects at all. I will be happy to reverse engineer and do discovery to fixed bid a replacement, but I will not entertain even hosting ancient client code on my company's servers, let alone thinking that we could reasonably make changes to the system without blowing it up. Can the DB even handle the changes? is the code spaghetti? are there 3rd-party components that no one knows about? are there licensing issues with code changes (or use of those 3rd party components)? As you noted, the effects of even minor changes are simply unknowable, and often a 'clean' app from the ground up will hit the need much more truly than another add-on to a system that already doesn't meet the user's need (if it was solid, they wouldn't be talking to me in the first place ...).
@Jason, I tend to agree. We will still do code edits, but prefer not to as we have to tell the client "we have no idea how long this will take, whether it will work or what it'll break". We're really explicit now that if we touch the code we have no idea what it'll break, and unless they want us to create a suite of automated acceptance tests, we probably won't even notice if we've broken anything. We may just stop doing these projects as while they sometimes work out, they aren't much fun and there is a real chance you'll just annoy the client, burning some of their money to not add the value they'd hoped for.
@Rich, Probably not a bad idea.