Software Estimation Is Hard

So as part of my new role at Sportsvite, I am taking over the leadership of development on partner projects. These are usually slightly smaller projects that are either directly on our site, or somehow interfacing with our site. While they are smaller, they are a lot MORE of them. Like, currently we have six projects ongoing, and I have to estimate all of them.

I don't know how other software developers feel about estimating projects, but for me, it's always the most difficult part of my job. If I developed software like I estimated it, I would be in serious trouble - it would go something like this:

"Here is my code. It may or not work, depending on A, B, and C, and it could be right, but probably not, and you could probably take the expected response time and multiply it by 1.5 to get a more accurate number."

That probably wouldn't fly, right? But for some reason, in software estimation seems to work like that. I think that's kind of crazy, but there hasn't been any better methodology put out there, really? Has there?

From wikipedia on sofware estimation:

The ability to accurately estimate the time and/or cost taken for a project to come in to its successful conclusion is a serious problem for software engineers. The use of a repeatable, clearly defined and well understood software development process has, in recent years, shown itself to be the most effective method of gaining useful historical data that can be used for statistical estimation. In particular, the act of sampling more frequently, coupled with the loosening of constraints between parts of a project, has allowed more accurate estimation and more rapid development times.

So I am not alone! This is a problem for other people, which makes me feel better. There are methodologies:

Function Point Analysis
Proxy-Based Estimating
Evidence-Based Scheduling

The problem is that, especially in a small shop, we

a) don't have comparable projects that can be used to provide historical data, especially for partner projects that are often more one-off than core product development. I can say with some confidence how long it takes to add a new Struts 2 action and mapping - that part is easy, but what about the elements on the page? What about the logic?
b) don't have the infrastructure in place to really record time spent on any one task, and often find that if we did, it would be inaccurate because we wear so many hats, each hat being taken on and off randomly throughout the day/week.
c) can't afford just yet to spend a lot of time making exhaustive estimates, because that's time that won't be spent in construction and testing.

I wish there was a silver bullet that you could shoot at this problem, but it seems like there isn't. Like anything else, there has to be a point where you make something a priority to really solve it, but it's become such a joke in the industry it seems, that people aren't trying too-too hard to really get good estimates.

Ah well, if anyone has an idea, or a good experience as a successfull estimator at a small software outfit, please feel free to leave a comment describing how you did it well.