I Just Need An Estimate

Throughout my career, it's been rare to be on a project where I am not asked for some sort of software estimate. No one likes estimating but I am diligent and do my best estimating how long developing something that I've never done before will take. But how are these estimates used? One common thing I've seen is taking an hour estimate multiplied by some constant to determine the "project cost". The constant is usually based off of loaded salaries and number of people involved. That dollar amount is not the cost of the project. It isn't that this number is off by some kind of factor, it is that it is almost unrelated.

So let's ignore the common issues when estimating. Ignore calendar time vs working hours time. Ignore staffing changes or priorities changing. Assume the features will be added in such a way to not accumulate technical debt. Let's assume the time estimate is 100% accurate (which happens 0% of the time). Can you now multiply it by a constant to get the cost? Nope!

Software's True Cost

The obvious issue with this cost estimate is that hours isn't how salaries work. Software engineers are usually salaried. You pay staffing costs whether you take on a new project or not. You still have to pay them even if you give your engineers nothing to do. It also doesn't go up if they work overtime (usually exempt from overtime pay). Your cost isn't in hours. This is different for contractors, hourly employees, or companies with lots of turnover. But generally it isn't the case where you can decide not to do a $100K project and then have $100K left in the bank. Maybe if a project is 100% outsourced this can be close to true; there are always costs regarding managing the project internally though.

This gets into the issue of opportunity costs. Your staff probably won't sit around idle if you don't give the go ahead for a project. There are always other projects or features to do or to help with support or clean up technical debt. There is always more things to do than time. People like contributing and will do the best they can to make a difference. Unless you can massively change the number of staff you have quickly, taking on one project means you won't be doing any number of other projects in the same time. Delays, scope reduction, or cancelation of other work is part of the project cost. I've been on a project providing a prototype / demo for something that would never be sold to anyone that left important and profitable work being delayed. That project cost a whole lot more than the wasted hours. Our main product was neglected during this time and we weren't in nearly as strong of a market position as we'd otherwise be. Whoops!

Ongoing Future Costs

But probably the biggest factor in a project's cost is not the initial cost but future costs — and don't mean fixing the bugs you missed. While software design and source code are considered engineering details, they have a massive impact on the overall organization. If you asked me to add a feature to one application and to add the exact same feature to a totally different application, how long it would take would vary greatly. This is due to overall system structure, non-functional requirements, what other needs the software meets but also software complexity.

Complexity doesn't grow linearly. As an example, take an application with 4 different on-off settings. The possible number of setting combinations you could have is 16. If you add a new setting now you have 32. But if you do the same thing to an application that has 10 settings, you've just added 1024 more possible combinations! This is a simplistic example but it has a profound impact in software development. Software complexity makes everything harder. It is harder for engineers to understand and work in. It is harder to test. There will be more bugs and surprise edge cases. Technical support is harder. Complexity is very expensive! Any time you add a feature, change a requirement, fix a bug, you are usually increasing the software complexity.

So unless you are just doing billable work for a customer where the customer pays the entire software maintenance cost, the cost of complexity is yours to bear. But don't worry, it gets worse than that. As your software gets larger and more complex, you'll have to increase staff. More people means communication becomes more difficult. You have more people who have to communicate with each other and miscommunications will be more common. You'll have more coordination costs and management costs for more staff. You will be paying the cost of a 2 week project years later.

There are likely even more aspects of software development costs that I haven't addressed. What is important to realize is that these costs are far more significant than the number of hours it takes to do a project. Project timelines matter for all sorts of things between making commitments to customers or investors, planning out when to do what, and prioritizing work. But the number of hours doesn't tell you much when it comes to knowing what a project will cost.

Don't Forget About Profit

With all these gotchas when it comes to software cost, one thing is quite evident; developing software is very expensive. This is why it is important to do proper analysis on features and projects. Work on things that are valuable to all customers. I've been on a number of projects that have been canceled or cut short. This is incredibly expensive. One of the most expensive things you can do is to tell developers to just "make it all work". You have to prioritize.

So it is understandable to care about software costs and to try to understand it. But it is a mistake to just take hours, multiply by some constant, and then compare it to expected revenue. Managing a business is much harder than that.

The upside is that the benefits of software can be way beyond the initial project too. A project that might be for one customer could potentially be sold to other customers. Or maybe it could be modified in a future project to be more generally useful. This is the business of software; develop it once, sell it everywhere. So if you are developing a product and you really need to know exactly the cost to know if it will be profitable, then you are in a very bad position indeed. It means the amount of profit you expect to get from it is very limited. Maybe consider a different product or approach.