Many places have a heavy process for hardware changes. ECN paperwork and such for even little changes during development and lack development bug tracking. SW bugs are usually tracked quickly and efficently using software like Bugzilla and can be “fixed” much easier from this standpoint.

I advocate using a bug tracking system, like Bugzilla, for ALL defect tracking, Software, Hardware, Documentation, Process, and so on. Setup categories for each of these with owners in the appropriate department. Separate it by product, and always include some general “products” that aren’t products like “Process”, “IT” or “Engineering Server”, or “Company”. And that way you can track everything.

A bug would get entered on a product. An initial category can be set by the reporter (for example say it’s a hardware problem and it’s an actual obvious hardware issue). And as comments and discussion accumulates, perhaps it is decided that the best fix is in a different area. For our example, perhaps we decide it’s best (easier/cheaper whatever, just think engineering trade-offs) to fix it in software. Change the category to software and fix it.

Make it easy to fix and switch catagories of problem and it’s no longer “that’s a software problem”, it becomes “that’s a problem, lets figure out the best engineering decision to fix it.”

- S.

Expediency is fine when its actually expedient! These decisions that were rooted in sound business logic over time become calcified into organizational traditions. It becomes its a S/W problem because the H/W (who messed up the first design) is too busy designing the next generation design to address it in H/W so we’ll just do a quick S/W hack and another and another

Another thing that happens is most firms have a software defect tracking process that is more or less tied into the S/W release process but because of the historical context they do not have a similar capability on the H/W side or a way to properly assign problems in the first place. In some cases the most efficient solution might be a combination of S/W and H/W changes but this is unlikely to be expedient.

I think the underlying problem that this thread exposes is the siloed organizational structure that dominates most engineering design teams. It used to make sense because of the wide chasm in tools and skill sets. But as time to market become more and more critical and the technology and techniques cross pollinate this structure makes less and less sense. What you really want are collocated teams of H/W and S/W engineers who have some cross training.This would allow both sides to have some appreciation for the difficulties of “driving a screw with a hammer” so to speak.

I think that what is most often really meant when this statement is made (in the context of resolving a problem) is:

“how can the problem be resolved in the most EXPEDIENT way”

Expediency != Efficiency.

This is precisely why I have tried to focus the discussion more clearly on the concept that what people mean when they say they are “fixing the problem in software” is actually: “masking a lower level problem at a higher level”.

As you say, there really isn’t a clear line between hardware and software, and certainly there must be a high degree of cooperation between developers at all levels/layers throughout a system.

I think everyone agrees that fixing the root cause is the only correct solution. I maintain that if a full economic analysis is done, that it will always be more cost effective to fix the root cause (in the long term).

While Sam is certainly correct in his assertion that there are times when it is necessary to bear the extra costs associated with the higher level hack, in order to (for example) meet a market window; this doesn’t alter the fact that it will always be more costly to mask the symptoms, than it would be to fix the root cause (in the given example, it is simply a cost that must be borne in order to maintain the products market viability).

In embedded systems, the SW and HW designers should be much closer and communicating constantly because there are many tradeoffs that can avoid dumping all the complexity on one or the other. In smaller designs, the SW and HW designers are the same person.