In short, on both sides of the old one-two punch, the hardware guys have got advantages.
1) When someone buys custom built hardware, they know what they want, and the specifications for it. When someone buys software, they want "something that does xyz, is just like facebook and paypal, but also has our logo." And then it turns out that the problem they're trying to solve is completely unrelated to any of those things. But you can just rewrite it to do those things too, right?
2) If there's a problem with the hardware, the customer that paid the money for custom chips will notice, and will have the technical skill to lay the blame on the vendor accurately. This means hardware manufacturers need to deliver quality, and since point #1 guarantees they actually have a specification, they can therefore engineer to it. In software, often the client takes your application, puts it on machines from the mid 90s that it won't run on, gives it to minimum wage employees to use (so management may not really care if it works), and then ask if its too late for the product to also be an app on their iphone. When they can't do anything with it 3 years later because it was written by people who have never looked at a computer before, the customer will just say "software always has bugs / always going out of date, find a new consulting company to write us a new one", as if its normal to have to build a completely new system to do the same thing over and over again every three years.
Software is held to much lower engineering standards because it can be made much more complicated, by most measures of complexity; and complexity in hardware drives up development and per-unit costs, whereas complexity in software drives up upfront costs only, so most people push complexity into software.
Consider an all-mechanical watch. Even a watch that just accurately displays time and day of week is going to be fairly complicated. If you want the day of month to account for the length of different months, that's more complicated again, and if you want to account for leap years, especially the mod-100 years that's more complicated again. To say nothing of products like the Calibre 89 [1].
A product like Pebble will do all that without batting an eyelid, and a hundred other things that would be impossible to do mechanically. Setting the time automatically. Programmable watch faces. Scheduling meetings and synchronizing with other watches, phones and computers. Correcting across time zones and daylight savings transitions. Accessing real time train schedules and weather.
Every engineer on my team has a characteristic "fudge factor" that represents his... optimism (say, from 1.5x to 2.5x). Once I apply those fudge factors, I add another 30% slack to the total schedule. And I usually still underestimate.
The team I'm on now has been doing a very good job compared to previous ones about getting good estimates for project duration, but the ability to underestimate is nonlinear in the project size, and most of our projects recently have been pretty small chips.
On our most recent tapeout, we did a new baseline based on a new feature request and underestimated the cost of that feature addition by a factor of 2. The total schedule was pushed out about 20% as a result. I still consider this a success in predicting the project's duration: I've been on projects where we taped out six months or more after our "commit" date.
People hiring consultants to build them software are generally non-technical. On most projects the following problems may occur:
Problems With Clients:
1) They don't konw what they really want.
2) They are bad at communicating what they really want.
3) Not enough people from the organization are brought in to weigh in on their needs / actual duties.
4) Too many people are brought in, many with conflicting interests. (bike shedding). [1]
5) Critical omissions are made regarding idiosyncrasies of their infrastructure that are never brought to light until far too late in the project.
6) people trying to change the direction of a project late into development
7) complicated/redundant policies or procedures which are incompatible or inefficient to implement using the tools the client requires you to implement them in.
Problems with Consultants / Contractors:
1) Over confident estimates
2) They are bad at estimations / unfamiliar with the tools required to do the job
3) They are bad at communication / rooting out the the real problem early
4) Unable to detect confusion/bullshitting from a client or are unwilling to investigate it.
5) PMs who make promises they are unable to keep
6) PMs who do not understand the details and make decisions without consulting those who do
7) Developers who avoid asking the client for clarification
8) spineless developers/PMs who screw themselves to avoid confrontation
9) Procrastination
[1] http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
8 isn't just about confrontation, the person who says 'yes' is more likely to not be fired than the person who says no. You need to frame all of those times you say no as alternatives, not as flat saying no.
Within reason, I completely disagree with this. The best engineers and PMs are the ones who effectively manage expectations.
"It's OK, it doesn't need any code changes, just a modification to the configuration files, so the approval process does not apply."
That company's developers just need to learn the trick of making the configuration file format Turing-complete.
If you don't have time to write your own interpreter, XSLT is an easy one to sneak by PHBs.
I've seen one system where 70-80% of the functionality was implemented in XSLT for this reason. It meant changes could be delivered in 5 days instead of 35. Obviously good news for the customer. The PHBs were pleased that the bug count in the C++ core had dropped (it hadn't really, we just stopped using the buggy modules.) The integration testers were pleased that the end product worked. Basically everyone was happy except the C++ reviewers in QA.
Because software is magic for a lot of people anyway that excuse just doesn't work.
We don't do the same with software, though I would argue that we should.
Based on my experience, the more time you spend coming up with application prototypes that closley resemble final products, more accurate estimates you will get from engineers.
Hardware engineering is possible as physics is the boundary and since has become categorically managed by human's mind of structure and logic. A jumbo jet can be decomposed to millions parts each confined by own specification therefore once design is done the production timeline is easy to estimated.
Software production to this day is still struggling between modular development and any attempt to standardize on a way to create software is overwhelmed by thousands of new frameworks or libraries even engineering methodologies every day. The reason software has such "joy" is because not like material or aerodynamic physics, software and way of making software are frequently derailed by its foundation, computer chips new advancement. Literally, every few years whoever can exploit the new capabilities of computer hardware has a chance to become next Steven Jobs.
Granted, most of corporate enterprise software projects don't have to aim high and certainly can be managed like any consumer production manufacture, so long as people are willing to settle on certain software framework, engineering approach, and treat pre-existed software component like real "physical" component meaning quit thinking the possibility of customize anything, simply focus on assembling. This is the engineering propaganda from school of IBM, Microsoft and SAP et al have been trying for decades but reality is no one but the labor cost sensitive offshore software firm would be interested to this. Everyone in corporate world pretend they're working in a creative campus and fancy about the software they make is the core competitive edge of their employer. The price to pay is uncertainty, but the question to ask is if their employer is in the business is in software business. The hard part is even this question is full of uncertainty, who'd imagine Walmart will be compete on the software it runs based on its past business model, well that might change.
The art to be able to estimate accurately (heck, even Boeing failed 787 estimate) is to turn craftsmanship to production assembling line. Stop thinking creatively, focus on manage a collection of proven engineering approaches of "manufacture" features meeting requirement. Everyone in software industry should realize there needs a distinct separation between the creative making of software world and the basic business operation needs. The line is not static though, as Google's engineers constantly made IBM's scalable/reliable enterprise software suite a joke. Still, not everyone is google and effectively manage the evolution of this distinction is not easy but necessary, because while google is looking for uncertainty, most of corporate enterprise hate uncertainty.
Once accepted the confined world, it will be possible to maintain a model of software composition by different combination of modular components, pre-existed or further decompose. The process can be fully automated and emulated as long as the time factor is added to each component. The upside is this can be estimate/managed down to minute level yet the downside is that the software created would be boring lack lust, but built with complexity to support operation reliably which is enterprise software all about anyway. Most importantly, once the estimate and cost become predictable, managing software system evolution will become a much easier and lucrative job. Imaging how joyful will it become if you go to your CFO asking for next round of upgrade (or even revamp) due to the "demand" of some fancy new capability the business users have experienced from their personal consumer digital gadget, while your commitment to the money and time has a solid track record.
The key to resolution to the challenge of corporate software engineering, including the majority of creative product builder in start ups, is the lack of an effective and efficient way to manage the software evolution and the chaos it brought. Sourcing to less cost labor or adding more bodies to the equation will not make it better, except short term psychological benefit.
In sum, software industry desperately needs automation. Ironically, software starts as the automation king to everything else, but itself has been largely remained in the hand of artist. The good news is cloud and DevOp are closing fast to bring an end to the nightmare of software engineering, at least an interim until the day software is no longer made by human.