5 ms·

The issue is design and development methodology. > "Spend some time with the other team" How about design documents? Is that truly a lost art among the latter

The issue is design and development methodology. > "Spend some time with the other team" How about design documents? Is that truly a lost art among the latter-day geeks?

hanniabu 2y ago
Everybody hates reading documentation
- seb1204 2y ago
  I read it but there is less and less available. Presentation and video recordings are more common but useless for the self study and search of information. Writing good documentation and instructions is hard. I try it a lot.
gnfargbl 2y ago
I'm sure that these groups are producing specifications, and I'm sure those specifications are being followed to the letter (and perhaps even being validated as such). The problem is that the spec only ever contains about 80% of reality, with the rest being lost either to implicit assumptions made by the writer, or to requirements that the implementer couldn't possibly hit and can't know (unilaterally) how to trade into something more realistic. This is why you have to get the humans to talk to the other humans. If that communication happens via a collaborative design document then yes, that's a process, and it's one that can work.
- SoftTalker 2y ago
  It's also why we could not recreate a Saturn-V today. We have the specs, but we don't have the knowledge and skills of the people who actually built them.
  - buildsjets 2y ago
    Even if you have the specs, you do not know if there was some important variable that was not referenced in the specs, and then you need a billion dollar research project to figure out what was missing from the original spec. Reference: FOGBANK. https://www.twz.com/32867/fogbank-is-mysterious-material-used-in-nukes-thats-so-secret-nobody-can-say-what-it-is https://www.twz.com/32867/fogbank-is-mysterious-material-use...
  - whatshisface 2y ago
    Another issue is that the same types of nuts and bolts, resistors, and other miscellanea are not manufactured today.
tonyarkles 2y ago
I tried and tried to get two teams who were working on critical-but-independently-developed systems to put together an ICD. Team 2 says "no problem!" and comes back with a document 2 weeks later. Team 1 says "this proposed interface is terrible, here's a much better way to do it". Team 2 replies "oh yeah that's a nice interface but too late the interface in the ICD is the one we built two months ago can't change it now"
3o495u 2y ago
Yes In my current role (high-assurance deterministic code for self-driving cars, one of the top-tier players, a company who claims to be "safety obsessed"), we have close to zero documentation. Every team or department has their own standards for documentation. Documentation is always back-written after coding is complete. Requirements are written after code is complete. For the past year, I've been given tons of praise at department meetings, "look at so and so, they've written so much really good documentation, their docs are the standard everyone else needs to follow", and then when it comes time for promotions my managers tell me "well, you haven't shipped as much code as other people on the team .... absolutely you've done a terrific job with documentation and we totally recognize you caught a ton of problems before they became problems, but promotions are really based on 'results', and 'results' means how much code you wrote ....". So I'm job hunting.
- brookst 2y ago
  Ah yes, the old “we’re really looking for people who know how to game the metrics rather than wasting time on long term value to the company and our customers” conversation. Sorry to hear it, but wow do I know just what you mean.
- bumby 2y ago
  Anecdotal personal experience in safety-critical design: A team was tasked with modernizing their multi-million dollar decades old test stand. The entire time they were cursing previous engineers for their lack of documentation that made reverse engineering difficult. Then when it came time for them to produce the documentation on their own design, they balked at the idea. I had a conversation with them about how they are screwing over the future engineers just like they were screwed over, but they still maintained cost/schedule pressure was too much to comply. We settled on them being allowed to go forward as long as they set aside a fund source and a date to have the documentation complete. When that date came and went, the documentation wasn't done and the excuse was the funding was used up by other projects. I feel like I owe those future engineers and apology. I don't think I'd be so trusting/naïve today and would push back harder that if they couldn't get their documentation in order when the design was fresh in their mind, they're even less likely to do so in the future.

The issue is design and development methodology. > "Spend some time with the other team" How about design documents? Is that truly a lost art among the latter-day geeks?

hanniabu 2y ago

Everybody hates reading documentation

seb1204 2y ago
I read it but there is less and less available. Presentation and video recordings are more common but useless for the self study and search of information. Writing good documentation and instructions is hard. I try it a lot.

gnfargbl 2y ago

I'm sure that these groups are producing specifications, and I'm sure those specifications are being followed to the letter (and perhaps even being validated as such). The problem is that the spec only ever contains about 80% of reality, with the rest being lost either to implicit assumptions made by the writer, or to requirements that the implementer couldn't possibly hit and can't know (unilaterally) how to trade into something more realistic. This is why you have to get the humans to talk to the other humans. If that communication happens via a collaborative design document then yes, that's a process, and it's one that can work.

SoftTalker 2y ago
It's also why we could not recreate a Saturn-V today. We have the specs, but we don't have the knowledge and skills of the people who actually built them.
- buildsjets 2y ago
  Even if you have the specs, you do not know if there was some important variable that was not referenced in the specs, and then you need a billion dollar research project to figure out what was missing from the original spec. Reference: FOGBANK. https://www.twz.com/32867/fogbank-is-mysterious-material-used-in-nukes-thats-so-secret-nobody-can-say-what-it-is https://www.twz.com/32867/fogbank-is-mysterious-material-use...
- whatshisface 2y ago
  Another issue is that the same types of nuts and bolts, resistors, and other miscellanea are not manufactured today.

tonyarkles 2y ago

I tried and tried to get two teams who were working on critical-but-independently-developed systems to put together an ICD. Team 2 says "no problem!" and comes back with a document 2 weeks later. Team 1 says "this proposed interface is terrible, here's a much better way to do it". Team 2 replies "oh yeah that's a nice interface but too late the interface in the ICD is the one we built two months ago can't change it now"

3o495u 2y ago

Yes In my current role (high-assurance deterministic code for self-driving cars, one of the top-tier players, a company who claims to be "safety obsessed"), we have close to zero documentation. Every team or department has their own standards for documentation. Documentation is always back-written after coding is complete. Requirements are written after code is complete. For the past year, I've been given tons of praise at department meetings, "look at so and so, they've written so much really good documentation, their docs are the standard everyone else needs to follow", and then when it comes time for promotions my managers tell me "well, you haven't shipped as much code as other people on the team .... absolutely you've done a terrific job with documentation and we totally recognize you caught a ton of problems before they became problems, but promotions are really based on 'results', and 'results' means how much code you wrote ....". So I'm job hunting.

brookst 2y ago
Ah yes, the old “we’re really looking for people who know how to game the metrics rather than wasting time on long term value to the company and our customers” conversation. Sorry to hear it, but wow do I know just what you mean.
bumby 2y ago
Anecdotal personal experience in safety-critical design: A team was tasked with modernizing their multi-million dollar decades old test stand. The entire time they were cursing previous engineers for their lack of documentation that made reverse engineering difficult. Then when it came time for them to produce the documentation on their own design, they balked at the idea. I had a conversation with them about how they are screwing over the future engineers just like they were screwed over, but they still maintained cost/schedule pressure was too much to comply. We settled on them being allowed to go forward as long as they set aside a fund source and a date to have the documentation complete. When that date came and went, the documentation wasn't done and the excuse was the funding was used up by other projects. I feel like I owe those future engineers and apology. I don't think I'd be so trusting/naïve today and would push back harder that if they couldn't get their documentation in order when the design was fresh in their mind, they're even less likely to do so in the future.