I do mission critical embedded systems in C. I follow the SE INCOSE process if one is not mandated eg DO-178 or 60601.
We do need good tools, from languages to requirements. Problem is the requirements tools and testing tools are very expensive. The process also takes a long time.
Keep in mind the shuttle code is $1000/LOC.
The only reason I can use C is I follow the process and my code is very defensive. It is very simple, reads like a child primer. I take the text of the requirements and make them the comments.
We need tools that don't allow a class of bugs, like buffer overflow.
I have listened to uncle Bob, but I have not yet heard his scree on women, etc.
What I did get is he seemed to be talking to the programmers with less than 5 years experience. He makes the valid point that if the number of programmers double every 5 years. then half of all programmers have less than 5 years of experience. If that is his target audience for more rigor. I have to agree with him.
It is incumbent on senior developers to both follow good practices and to mentor younger developers. And management to support the developers with good tools and the resources to be able to do a good job. This includes realist schedules. Good, fast, cheap, choose any two. If you choose fast and cheap, you cannot expect to fix the code to be good. The process greatly increases the likelihood of good. Fast and good are mutually exclusive. Good and cheap are mutually exclusive.
I am looking at Rust. It is an example of a tool that doesn't allow a certain class of bugs. Any overhead can be handled by a faster mpu. Does that increase costs per unit? Probably. But pay me now or pay me later. A lot depends upon how much risk management is willing to accept.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I do mission critical embedded systems in C. I follow the SE INCOSE process if one is not mandated eg DO-178 or 60601.
We do need good tools, from languages to requirements. Problem is the requirements tools and testing tools are very expensive. The process also takes a long time.
Keep in mind the shuttle code is $1000/LOC.
The only reason I can use C is I follow the process and my code is very defensive. It is very simple, reads like a child primer. I take the text of the requirements and make them the comments.
We need tools that don't allow a class of bugs, like buffer overflow.
I have listened to uncle Bob, but I have not yet heard his scree on women, etc.
What I did get is he seemed to be talking to the programmers with less than 5 years experience. He makes the valid point that if the number of programmers double every 5 years. then half of all programmers have less than 5 years of experience. If that is his target audience for more rigor. I have to agree with him.
It is incumbent on senior developers to both follow good practices and to mentor younger developers. And management to support the developers with good tools and the resources to be able to do a good job. This includes realist schedules. Good, fast, cheap, choose any two. If you choose fast and cheap, you cannot expect to fix the code to be good. The process greatly increases the likelihood of good. Fast and good are mutually exclusive. Good and cheap are mutually exclusive.
I am looking at Rust. It is an example of a tool that doesn't allow a certain class of bugs. Any overhead can be handled by a faster mpu. Does that increase costs per unit? Probably. But pay me now or pay me later. A lot depends upon how much risk management is willing to accept.