3 ms·

We were under contract to deliver them a working design, both hardware and software, which they would then manufacture. Basically outsourced R&D. So software w

We were under contract to deliver them a working design, both hardware and software, which they would then manufacture. Basically outsourced R&D. So software was part of the deliverable. It was their product, their risk, after all. We didn't do this for long, just to pay the bills until we had our own products that were making us money.

BeetleB 3y ago
Makes sense. The approach would then be to inform them that "We'll comply with MISRA, but you'll get poor code quality." It's their choice. Put yourself in their shoes. As they're not doing the coding, it's riskier for them to sit with you and understand the code and all the exceptions you made to MISRA.
- lordfrito 3y ago
  > The approach would then be to inform them that "We'll comply with MISRA, but you'll get poor code quality. Which we did. > Put yourself in their shoes. Oh, I get it. I understand where they were coming from. My complaint isn't with the customer, its with MISRA being a poor tool and ripe for this kind of abuse. Because my customer needed to point to something, they point to MISRA, not understanding this isn't entirely helping them. I loath tools that can be abused this way. Dumbs everyone in the room down. Next you get experts in MISRA that waste everyone's time talking about how wonderful it is. I'm all for scrutinizing code, but don't waste my time scrutinizing code needlessly.
  - BeetleB 3y ago
    > My complaint isn't with the customer, its with MISRA being a poor tool and ripe for this kind of abuse. Any guideline/linter is ripe for abuse. I don't see MISRA being an outlier in this regard. Had everything been developed in house, MISRA wouldn't have been the bottleneck. You'd ignore whatever MISRA rules are not relevant, and note the exception down formally, and be done with it. My job in that company was primarily to understand the automotive ISO guidelines, and inform the team about what was OK and what wasn't, and to write those rationales for the auditor(s). As an extreme example, for one component, the ISO standard allowed us to ignore almost all the guidelines because if it has been tested heavily, it suffices as evidence the component is safe. For that component, we felt it cheaper to test the heck out of it than to conform to the guidelines. We tested it by running it continuously for months, feeding in random inputs. Cheaper to have a computer do it than highly paid engineers getting bogged down. Even in a contracting scenario, this could have been avoided. You'd write your exceptions, and the customer would get an auditor to go over your exceptions, and be done with it. Don't blame guidelines for poor organizational behaviors. As I said elsewhere, the ISO guidelines allow you to be sane about it. Think of the plus side, though. If you had gone the route you wanted, you would have to read several hundred pages of an ISO standard multiple times before you could be well versed enough to know when it's OK to violate the guidelines. Reading those documents is a lot worse than following MISRA ;-)
    - lordfrito 3y ago
      > Any guideline/linter is ripe for abuse. > Don't blame guidelines for poor organizational behaviors. Oh for sure. > I don't see MISRA being an outlier in this regard. Had everything been developed in house, MISRA wouldn't have been the bottleneck. I respect your perspective. I was in charge of setting in-house guidelines, and tried to do things sanely. Personally I found that the entire team saw much less value in MISRA, but could clearly see the value in LINT. Mainly because MISRA seemed (to us) to be pretty obvious stuff, while LINT seemed to encourage everyone to develop better coding habits. YMMV

BeetleB 3y ago

Makes sense. The approach would then be to inform them that "We'll comply with MISRA, but you'll get poor code quality." It's their choice. Put yourself in their shoes. As they're not doing the coding, it's riskier for them to sit with you and understand the code and all the exceptions you made to MISRA.

lordfrito 3y ago
> The approach would then be to inform them that "We'll comply with MISRA, but you'll get poor code quality. Which we did. > Put yourself in their shoes. Oh, I get it. I understand where they were coming from. My complaint isn't with the customer, its with MISRA being a poor tool and ripe for this kind of abuse. Because my customer needed to point to something, they point to MISRA, not understanding this isn't entirely helping them. I loath tools that can be abused this way. Dumbs everyone in the room down. Next you get experts in MISRA that waste everyone's time talking about how wonderful it is. I'm all for scrutinizing code, but don't waste my time scrutinizing code needlessly.
- BeetleB 3y ago
  > My complaint isn't with the customer, its with MISRA being a poor tool and ripe for this kind of abuse. Any guideline/linter is ripe for abuse. I don't see MISRA being an outlier in this regard. Had everything been developed in house, MISRA wouldn't have been the bottleneck. You'd ignore whatever MISRA rules are not relevant, and note the exception down formally, and be done with it. My job in that company was primarily to understand the automotive ISO guidelines, and inform the team about what was OK and what wasn't, and to write those rationales for the auditor(s). As an extreme example, for one component, the ISO standard allowed us to ignore almost all the guidelines because if it has been tested heavily, it suffices as evidence the component is safe. For that component, we felt it cheaper to test the heck out of it than to conform to the guidelines. We tested it by running it continuously for months, feeding in random inputs. Cheaper to have a computer do it than highly paid engineers getting bogged down. Even in a contracting scenario, this could have been avoided. You'd write your exceptions, and the customer would get an auditor to go over your exceptions, and be done with it. Don't blame guidelines for poor organizational behaviors. As I said elsewhere, the ISO guidelines allow you to be sane about it. Think of the plus side, though. If you had gone the route you wanted, you would have to read several hundred pages of an ISO standard multiple times before you could be well versed enough to know when it's OK to violate the guidelines. Reading those documents is a lot worse than following MISRA ;-)
  - lordfrito 3y ago
    > Any guideline/linter is ripe for abuse. > Don't blame guidelines for poor organizational behaviors. Oh for sure. > I don't see MISRA being an outlier in this regard. Had everything been developed in house, MISRA wouldn't have been the bottleneck. I respect your perspective. I was in charge of setting in-house guidelines, and tried to do things sanely. Personally I found that the entire team saw much less value in MISRA, but could clearly see the value in LINT. Mainly because MISRA seemed (to us) to be pretty obvious stuff, while LINT seemed to encourage everyone to develop better coding habits. YMMV