5 ms·

For what it's worth, I haven't seen hardware engineers complaining about this issue as much as software engineers, which I find baffling. I think if you're goin

For what it's worth, I haven't seen hardware engineers complaining about this issue as much as software engineers, which I find baffling. I think if you're going to justify why software development is such a "hard" problem, you should mention what makes it so different from other fields.

kwantam 13y ago
You've been talking to the wrong hardware engineers, I think. 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.
pratik661 13y ago
Its much easier to justify changes in software requirements vs changes in hardware requirements because the perceived cost of adding a few more features on your application is low. Compare that to say.. adding another register to your chip..which might add millions to the whole production process. The changes can be made while the app is live. You can not do that for hardware.
- analog31 13y ago
  I've seen the opposite, where the effort and bureaucracy to change the software is so prohibitive that changes are made to electronics or even mechanics to avoid a software change.
  - gnarbarian 13y ago
    he's talking about in the middle of a project. Not some giant legacy software system written in cobol running on a 30 year old mainframe where all original developers are dead and no original source code or documentation exists.
  - finnw 13y ago
    > ... to avoid a software change. "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.
    - analog31 13y ago
      Beautiful, Greenspun's Tenth Rule comes to the hardware department!
gnarbarian 13y ago
Hardware engineers have more clearly defined requirements, It's also well understood by everyone that you can't just change the design halfway through production with no additional cost. Hardware engineers clients are mostly other engineers who know their shit very well. Hardware engineering is also more formalized with a larger percentage of engineers actually possessing relevant degrees with common well established means of communicating and thoroughly clear phases of development for a project. 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 http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality
- ohyes 13y ago
  8 and 3 are the biggest in my opinion. 3 should have it added that the we are bad at getting the requirements out of customers, then writing it down and sticking to what is written. 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.
  - 13y ago
tmoertel 13y ago
Here's the thing. Software is profitable at much lower quality levels than the hardware market will tolerate. As a result, most hardware is designed through a process that could accurately be called engineering, even though most software is not. So hardware engineers get to make estimates with the benefit of having fairly reliable engineering outputs to use as estimating inputs. Further, the business side of hardware is more culturally attuned to the realities of engineering and is therefore less likely to challenge estimates coming out of mature engineering processes. In short, on both sides of the old one-two punch, the hardware guys have got advantages.
- wisty 13y ago
  So the hardware estimate is more "how long will it take to debug the prototype, and bring it to production"?
  - ep103 13y ago
    More like, 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.
pcurve 13y ago
In hardware design, there is more up-front time making prototypes and running simulations, so that engineers have clearer ideas about what they will build and how they will solve problems. 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.
venomsnake 13y ago
I have been in a company where we developed hardware and software. Well hardware - you have some hard stuff there - at the end the laws of physics give you a lower bound of stupidity that you can deal with. There are just times when you can write in reply to the manager with a cc to the CEO when answering the question - can we do it that way - with "Only if you send us to training in Hogwarts" Because software is magic for a lot of people anyway that excuse just doesn't work.
michaelt 13y ago
Engineer with hardware and software experience here. 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. [1] https://en.wikipedia.org/wiki/Calibre_89 https://en.wikipedia.org/wiki/Calibre_89
bitcuration 13y ago
The challenge of software estimation is rooted in software engineering. As much as software wants to be called engineering, its current state of art is still craftsmanship, more of development than engineering. 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.
sixothree 13y ago
And how often do hardware engineers have to deal with business logic and workflows.

kwantam 13y ago

You've been talking to the wrong hardware engineers, I think. 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.

pratik661 13y ago

Its much easier to justify changes in software requirements vs changes in hardware requirements because the perceived cost of adding a few more features on your application is low. Compare that to say.. adding another register to your chip..which might add millions to the whole production process. The changes can be made while the app is live. You can not do that for hardware.

analog31 13y ago
I've seen the opposite, where the effort and bureaucracy to change the software is so prohibitive that changes are made to electronics or even mechanics to avoid a software change.
- gnarbarian 13y ago
  he's talking about in the middle of a project. Not some giant legacy software system written in cobol running on a 30 year old mainframe where all original developers are dead and no original source code or documentation exists.
- finnw 13y ago
  > ... to avoid a software change. "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.
  - analog31 13y ago
    Beautiful, Greenspun's Tenth Rule comes to the hardware department!

gnarbarian 13y ago

Hardware engineers have more clearly defined requirements, It's also well understood by everyone that you can't just change the design halfway through production with no additional cost. Hardware engineers clients are mostly other engineers who know their shit very well. Hardware engineering is also more formalized with a larger percentage of engineers actually possessing relevant degrees with common well established means of communicating and thoroughly clear phases of development for a project. 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 http://en.wikipedia.org/wiki/Parkinson's_law_of_triviality

ohyes 13y ago
8 and 3 are the biggest in my opinion. 3 should have it added that the we are bad at getting the requirements out of customers, then writing it down and sticking to what is written. 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.
- 13y ago

tmoertel 13y ago

Here's the thing. Software is profitable at much lower quality levels than the hardware market will tolerate. As a result, most hardware is designed through a process that could accurately be called engineering, even though most software is not. So hardware engineers get to make estimates with the benefit of having fairly reliable engineering outputs to use as estimating inputs. Further, the business side of hardware is more culturally attuned to the realities of engineering and is therefore less likely to challenge estimates coming out of mature engineering processes. In short, on both sides of the old one-two punch, the hardware guys have got advantages.

wisty 13y ago
So the hardware estimate is more "how long will it take to debug the prototype, and bring it to production"?
- ep103 13y ago
  More like, 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.

pcurve 13y ago

In hardware design, there is more up-front time making prototypes and running simulations, so that engineers have clearer ideas about what they will build and how they will solve problems. 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.

venomsnake 13y ago

I have been in a company where we developed hardware and software. Well hardware - you have some hard stuff there - at the end the laws of physics give you a lower bound of stupidity that you can deal with. There are just times when you can write in reply to the manager with a cc to the CEO when answering the question - can we do it that way - with "Only if you send us to training in Hogwarts" Because software is magic for a lot of people anyway that excuse just doesn't work.

michaelt 13y ago

Engineer with hardware and software experience here. 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. [1] https://en.wikipedia.org/wiki/Calibre_89 https://en.wikipedia.org/wiki/Calibre_89

bitcuration 13y ago

The challenge of software estimation is rooted in software engineering. As much as software wants to be called engineering, its current state of art is still craftsmanship, more of development than engineering. 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.

sixothree 13y ago

And how often do hardware engineers have to deal with business logic and workflows.