A recent video had me considering the problems of software engineering cost estimation – something that has plagued software engineering. It has also plagued people who think software engineering is just coding because, frankly, they’re idiots.

Since I’m out of the industry – by my choice and on my terms – I can now tackle some topics and speak my mind more freely without worry of repercussions when it comes to the next contract, or the next job.

The video is, “How To Price Design Services“, and I’ll embed it at the end of this post.

Now, when it comes to software cost estimation, we start off by gathering requirements. We come up with a design, or alternative designs, built on architectures and technologies that may be new or not, that a company might have the resources to do or not, etc. Some people call this ‘discovery’. Based on what is found in discovery, an estimate is done by reading tea leaves, a magic 8 ball, estimates of coders, and perhaps killing a gluten-free chicken and reading it’s entrails. That’s about as scientific as most people do it.

And how does one get the estimates? As a software engineer over the decades, I know an estimate given by someone writing code (not necessarily a software engineer) is:

• based on assumptions based on the documented or communicated (mistake 1) information that leads to assumptions (mistake 2).
• based on their skill level and experience, as well as innate ability.
• dependent on how much pressure is applied to them, with different thresholds for different individuals.
• usually wrong.
• never tied to the value for the company.

Now, I’m not saying that the value of a project for the company should be the estimate – far from it, that’s just not how business works. But let’s talk about profitability – immediate and recurring.

The immediate profit usually doesn’t work out unless a marketing department is brilliant, or there is a monopoly, or both. So it’s about recurring profit. How much would be expected as a return withing – oh, let’s say – 6 months?

The point is that there is a value associated with the project that is rarely communicated to the development team, which is usually – hopefully – smart enough to pick this apart. And the people asking for the project almost never want to let the development team know the value that they’re contributing because those salaried employees will want more money.

Meanwhile, every software project encounters problems because of technology changes, changes on the development team (a problem of poor hiring or poor retention policy), requirements creep (‘someone in the sales department just had a great idea!’), design flaws (they happen), architecture problems and…. well, just about everything.

The main problem with all of this is that estimates simply aren’t accurate – which, actually, is exactly what they are supposed to be. An estimate is never accurate. It approximates, and people don’t get fired too often off of teams because of their coding abilities, but because of their or someone else’s estimation abilities.

There is a point here. That point is that the development team is only as invested in the project as the business team and management permits them to be – and if they’re better invested… productivity will increase and there will also be more careful and thoughtful estimates.

Now, does ‘invested’ mean ‘more money’? Sometimes. Free gummi bears and a gym might work in Silicon Valley, but they also make a metric buttload more money than a development team in – oh, let’s say Orlando, Florida. No, that ‘incentive’ is to get people to stay physically in place in a brick and mortar establishment which, sadly, is still the norm. But they don’t actually make people tweak that bit of code just a little more efficiently. You don’t toss gummi worms at developers and they prance around.

It’s about being vested. And that’s the core problem of cost estimation – the developers are given a black box to fill with little to no actual information from the business.

Oh. That video:

[youtube https://www.youtube.com/watch?v=RKXZ7t_RiOE&w=560&h=315]