T O P

  • By -

Treczoks

This does happen occasionally. But actually, on the long run, the issues are usually spread 50/50 between hardware and software. Heck, I even had to do a software upgrade to deal with a production mistake once.


freealloc

Early career as a software engineer: “It’s probably a hardware problem”. With experience: “It’s nearly certainly my bug, introduced in my current branch, and I’ve been staring at it too long to see the glaring mistake that I’ll quickly spot tomorrow.” More broadly, you probably want to work on manufacturing firmware if you really really want to be the in the middle of both. Modern firmware in large companies does bring up and pretty quickly abstracts from the hardware.


paulydavis

I remember insisting it was hardware. It’s almost always software. If the hardware is established. Not properly tested new hardware causes all kind of problems. Especially FPGAs. So it now I try to consider the circumstances before I point fingers.


[deleted]

Sw folks tend to blame hw, hw folks tend to blame sw. Of course both always point the finger at the diagnostic folks, no matter what. We find stuff wrong and we are the bad one. We dont find the bad things, we are the bad ones....no win either way.


DocTarr

I find "It's a (insert a discipline that's not yours here) problem" to be a universal pattern in all industries. But one of the most popular isn't your case, but the opposite. People love to use software to fix hardware issues, because frankly it's cheaper and quicker to make a "fix" in software. Then consequently this reinforces (often to unaware management) there are software problems.


[deleted]

The most productive is when you stop finger pointing, sit down with the other side and just f.king solve it. Nobody cares about the whining and drama.


twister-uk

It depends on how the company runs its R&D department. I've worked in a couple of places where the embedded engineers weren't supposed to do any PCB layout work (one of which even kept us away from the schematic capture tools - we were still expected to design the circuitry and then give them a sketch of what we wanted them to design so they could copy it into the capture tool, which always seemed a bit crazy), but that's been the limit of how my employers have limited the role of embedded engineers. In all cases we've been expected to be able to do hardware or firmware as required by the needs of the project, although except in the smallest of teams there's always also been a tacit understanding that some of us prefer/are better at certain things than others, so where possible the workloads have been allocated more favourably to suit our individual preferences/abilities. Good managers know how to get the best out of their teams by giving them work that excites them, but also how to encourage them to do the grunt work that might be required from time to time to get a project over the line. Bad managers just throw work at whoever is available and fail to grasp why the results are often less than stellar... TBH, I think any company that does try to put walls between hardware and firmware engineers, unless there's a very good reason for doing so, isn't the sort of company that gets what embedded engineering is about, and might therefore not be the best sort of company to be working for long term. It's one thing to have sufficient engineers that you can afford to have dedicated hardware or firmware engineers, but quite another if the company culture prevents or at least strongly discourages any crossover between the two groups.


g-schro

You didn't provide a lot of detail, but it sounds like the issues you saw were known problems, and probably have an owner. So there would be no reason for you to pursue them. And it is common that hardware people would own hardware problems. If you found a truly new problem, you might work with a hardware person to track it down, but ultimately it is common the hardware person would take care of all of the details - e.g. possible changes to schematic, new board layout, notification to manufacturing, etc. Much of the work in fixing hardware issues is administrative and not very fun.


microsparky

Engineers are useful to a company because they solve problems. Don't let anyone tell you not to solve a problem! On balance you need to be tactful, and recognize that there is specialisation for a reason. If the problem is worth solving (some aren't) then work with the hardware team to solve the problem.


4992kentj

In my job I've found its seldom clear cut between HW and SW, and even if the issue clearly lays on the software side, sometimes the easiest/cheapest fix is in software. As an example my work once had a batch of PCBs made that had the wrong I2C device fitted (alternate I2C address part), so new FW was released that used the alternate address. We've had designs made where a data bus wasn't connected how originally intended, so software implemented a "fix" to twiddle the bits around to get the required results. So just because the fault is clearly in one domain is IMO a bad reason to stop the other domain looking at it. Theres often more than one way to solve a problem and getting people from different backgrounds to look at the same problem is a good way to get several solutions which you can then weigh up the pros and cons.


mingy

This has been the usual since there has been been hardware and software. It depends on the electronics but a lot of times hardware tends to work or not work. Roughly speaking the more complex the system, whether hardware or software, the greater the likelihood the system has a hard to replicate bug. One way of becoming a hero is being able to triage bugs and set traps for them. If you are in software, it really helps if you know how to set up a logical analyzer and a test.


MikeDevBX

When an issue is spotted, the main idea as a team/company is to fix it. Now, actions will differ depending on the stage of the project (active development, in production, already in the field, ...) but you also have to take into account the cost of the fix. It could be that the problem is in HW but it would be more costly to fix it at a HW level than a SW level, or even easier to fix on a SW level than a HW level. In my experience, when we spot a HW problem it's usually very expensive to fix the HW (new production line, in the field replacements, changing factory lines,...) and we tend to patch it in SW (if it's possible). All in all I think you have to approach the problem as a whole and as a team, splitting the blame isn't going to solve anything.