3 ms·

> Maybe that's what we need for software development. A structural engineer wouldn't use a composite material without knowing its performance characteristics. W

> Maybe that's what we need for software development. A structural engineer wouldn't use a composite material without knowing its performance characteristics. Why should a programmer use something like string collection from a language without knowing its performance characteristics? Up front, I don't disagree with you, but let me throw out a parallel benefit of your scenario here: For the most part, in software engineering, a building won't collapse if I'm fucking around with a language and doing sub-optimal things. If I need optimization, I probably know that going in, and would probably take the time to know exactly what language/features I should use. Since most software built today is pretty low risk/inconsequential if it fails, we might be moving the state of the art forward faster than they might in structural engineering simply because we have the freedom to fuck around and learn. We can test our materials in production, whereas I hope the dude that built my office can't. Like, yeah, definitely don't do this with medical devices and airplanes, but with CRUD app of the day, I might learn something when people decide to use it all of a sudden and it grinds to a halt. I dunno, I should say I'm not a real software engineer in the first place and am open to being totally wrong here.

ineedasername 5y ago
we might be moving the state of the art forward faster than they might in structural engineering simply because we have the freedom to fuck around and learn Thanks-- I think that's a very concise response & reflection on my comment. I still think we can & should do better, but you're right that the lower stakes probably lower the bar on acceptable crystallization of experience into best practices. Which is problematic because of things like writing a library for your own low-stakes project, but the library gets published on github and used by someone in a something that isn't low stakes. Maybe part of what we need are defined "stakes" levels and corresponding criteria for acceptable practices at each stage.
- SmellTheGlove 5y ago
  > I still think we can & should do better Totally! And I really like > Maybe part of what we need are defined "stakes" levels and corresponding criteria for acceptable practices at each stage. I think I'm going to start testing this with the TPMs and Engineers I work with. I'm going to ask a more senior TPM on my team to think about this and how it should be incorporated into our specs. My hypothesis is our engineers would be happier knowing about the risk profile of whatever failure modes we've id'ed, and they can design accordingly. That said, I don't really work on high risk software, so this is all relative. Most of our stuff is in the "push the button again" category if it dies.

ineedasername 5y ago

we might be moving the state of the art forward faster than they might in structural engineering simply because we have the freedom to fuck around and learn Thanks-- I think that's a very concise response & reflection on my comment. I still think we can & should do better, but you're right that the lower stakes probably lower the bar on acceptable crystallization of experience into best practices. Which is problematic because of things like writing a library for your own low-stakes project, but the library gets published on github and used by someone in a something that isn't low stakes. Maybe part of what we need are defined "stakes" levels and corresponding criteria for acceptable practices at each stage.

SmellTheGlove 5y ago
> I still think we can & should do better Totally! And I really like > Maybe part of what we need are defined "stakes" levels and corresponding criteria for acceptable practices at each stage. I think I'm going to start testing this with the TPMs and Engineers I work with. I'm going to ask a more senior TPM on my team to think about this and how it should be incorporated into our specs. My hypothesis is our engineers would be happier knowing about the risk profile of whatever failure modes we've id'ed, and they can design accordingly. That said, I don't really work on high risk software, so this is all relative. Most of our stuff is in the "push the button again" category if it dies.