RE: https://mastodon.social/@GeePawHill/116129976624712032

Riffing off @GeePawHill's tale of professional failure, I'm reminded of mine. Thankfully it was obvious to everyone in the room that the principal failure was the project managers not understanding/caring what the client wanted.

So our firm was modifying a severe reactor accident analysis program to model some very specific conditions related to the Fukushima accident. My role was converting pages of handwritten math to Fortran and handing off the routines to another team for integration into the main code.

The specific engineering question was very interesting: If you pour molten core debris ("corium") into a floor sump that drains into another sump via a pipe, how much corium flows into the second sump before the corium freezes solid and clogs the pipe? This is a weird and complex coupled heat transfer/fluid flow problem with changing geometry. Thankfully, it has a closed form analytical solution, it's ugly but it exists (see Carslaw & Jaeger's "Conduction of Heat in Solids" https://global.oup.com/academic/product/conduction-of-heat-in-solids-9780198533689 - $305 cheap!) There were a few wrinkles in our case that required modifying the stock solution but we managed to sort out all the math and the computation was straightforward. I wrote a set of subroutines, built a test harness, and formalized the documentation and software change report, and handed it off for integration. This was circa 2015-2016 and the reference code was built under OpenVMS on reconditioned Alpha hardware because certain managers refused to move to a supported dev environment and didn't want to pay to qualify modern commodity hardware that everyone else in the known universe used. So I built my code on a PC and threw it over the wall for integration because there was no way I could work effectively in OpenVMS after not touching it since 1990, even if I wanted to (which I didn't).

Aside: I did not get along well with the project manager for a bunch of critical professional reasons[*], the lack of modern version control was one and the head-in-sand refusal to move beyond 1989 technology was another. The project was a case study in everyone and everything existing as a fly trapped in amber due to the suburban incuriosity of comfortable life in the lily-white western suburbs of Chicagoland. Dupage County will rot your brain and your soul.

Anyway, the day came to present this work to our Japanese clients. The code had been tested, reviewed, and merged with no issues. It worked as intended. I spent 15 minutes explaining all that.

Them: "Is the corium in the entrance area of the pipe in a particulate or pebble form that could be easily vacuumed out of the sump piping?"

Me: "This model does not consider entrance or exit effects."

The very nice code very clearly did not answer the actual question the client cared about. The client was not happy but it was thankfully clear that I had successfully implemented what I was directed to implement by our management. More thankfully my management did not try to thrown me under the bus; the client was smart enough to realize this was a project management failure and that I was as much a victim as they were minus the fact that they indirectly paid me to deliver something they had no use for.

Still, it's embarrassing as hell to have done very solid professional work, present it to a group, and find out that it was completely useless in front of the high-level people writing the checks.

Unlike GeePaw's experience with the Canadian Coast Guard, there was no Comedy Officer.

[*] This is the manager who looked over my shoulder and asked what language I was programming in. I said "Fortran" and I'm fairly certain he did not believe me. Fortran 2008 looks almost nothing like the F77 he was still using. Mixed case, free format, block structure, modules, array operations, object model. The language is incredibly backward compatible and it can be a rude shock if you do not stay aware of the changes to the language over a quarter of a century.

I had some fantastic coworkers there but I do not miss that environment or worldview. At all.

RE: https://mastodon.social/@GeePawHill/116129976624712032

Riffing off @GeePawHill's tale of professional failure, I'm reminded of mine. Thankfully it was obvious to everyone in the room that the principal failure was the project managers not understanding/caring what the client wanted.

So our firm was modifying a severe reactor accident analysis program to model some very specific conditions related to the Fukushima accident. My role was converting pages of handwritten math to Fortran and handing off the routines to another team for integration into the main code.

The specific engineering question was very interesting: If you pour molten core debris ("corium") into a floor sump that drains into another sump via a pipe, how much corium flows into the second sump before the corium freezes solid and clogs the pipe? This is a weird and complex coupled heat transfer/fluid flow problem with changing geometry. Thankfully, it has a closed form analytical solution, it's ugly but it exists (see Carslaw & Jaeger's "Conduction of Heat in Solids" https://global.oup.com/academic/product/conduction-of-heat-in-solids-9780198533689 - $305 cheap!) There were a few wrinkles in our case that required modifying the stock solution but we managed to sort out all the math and the computation was straightforward. I wrote a set of subroutines, built a test harness, and formalized the documentation and software change report, and handed it off for integration. This was circa 2015-2016 and the reference code was built under OpenVMS on reconditioned Alpha hardware because certain managers refused to move to a supported dev environment and didn't want to pay to qualify modern commodity hardware that everyone else in the known universe used. So I built my code on a PC and threw it over the wall for integration because there was no way I could work effectively in OpenVMS after not touching it since 1990, even if I wanted to (which I didn't).

Aside: I did not get along well with the project manager for a bunch of critical professional reasons[*], the lack of modern version control was one and the head-in-sand refusal to move beyond 1989 technology was another. The project was a case study in everyone and everything existing as a fly trapped in amber due to the suburban incuriosity of comfortable life in the lily-white western suburbs of Chicagoland. Dupage County will rot your brain and your soul.

Anyway, the day came to present this work to our Japanese clients. The code had been tested, reviewed, and merged with no issues. It worked as intended. I spent 15 minutes explaining all that.

Them: "Is the corium in the entrance area of the pipe in a particulate or pebble form that could be easily vacuumed out of the sump piping?"

Me: "This model does not consider entrance or exit effects."

The very nice code very clearly did not answer the actual question the client cared about. The client was not happy but it was thankfully clear that I had successfully implemented what I was directed to implement by our management. More thankfully my management did not try to thrown me under the bus; the client was smart enough to realize this was a project management failure and that I was as much a victim as they were minus the fact that they indirectly paid me to deliver something they had no use for.

Still, it's embarrassing as hell to have done very solid professional work, present it to a group, and find out that it was completely useless in front of the high-level people writing the checks.

Unlike GeePaw's experience with the Canadian Coast Guard, there was no Comedy Officer.

[*] This is the manager who looked over my shoulder and asked what language I was programming in. I said "Fortran" and I'm fairly certain he did not believe me. Fortran 2008 looks almost nothing like the F77 he was still using. Mixed case, free format, block structure, modules, array operations, object model. The language is incredibly backward compatible and it can be a rude shock if you do not stay aware of the changes to the language over a quarter of a century.

I had some fantastic coworkers there but I do not miss that environment or worldview. At all.

@GeePawHill A few additional points:
While I find it very difficult to program in F77, I can and I will if it's the right thing to do for a project.In this case the project was a large 30 year old codebase that I had last touched in 1990 as an intern. This was the first professional software project I worked on and I learned a ton from it, a lot of good lessons I carry with me to this day.
The key thing to realize is that you are one of a long line of developers on an important project that people rely on for very serious work. It's not my job to _unilaterally_ change coding style and practice. IMO the best thing I can do is understand the development standards and practices and abide by therm as best as possible and put global and personal standards _second_. I will code and document and test to my standards where they exceed the project standards but what I ultimately deliver will should be as close to project standards as possible. This means using naming conventions, house formatting style, architecture, etc so my code looks like the best of the codebase. I'm essentially a warm body thrown into expanding the code, essentially an internal contractor. I didn't "own" this system and I make no group or project level decisions.

I fought like hell for the better part of a decade to get anyone on that team interested in CVS/SVN/git - any standard reliable version control system invented over the past 30 years - and failed. It's not like I don't care, it's that I am specifically NOT trying to disrupt the project.

Move methodically and fix things. Lock the techbro cowboys in the paddock with the bulls and go mend some fences.

@arclight @GeePawHill Ooh, can I play too?

https://blog.plover.com/tech/prudential.html

@arclight Any examples of good lessons you learned from that project?

@GeePawHill