4 ms·

> They are not judged by the quality of their code, but by the results their code produces. How much are software engineers judged by the code quality? And how

> They are not judged by the quality of their code, but by the results their code produces. How much are software engineers judged by the code quality? And how much by the end results (shipped features/projects)? There's a large gap between good code quality (i.e. keep the soft. engs. happy) and passable maintenance (i.e. features and bugfixes are not terribly late -- keep the execs/business happy). When it comes to Fortran, I wish it long life. It found a great fit and does its job well. Numerical math has many peculiarities. I'm happy we have stable libraries for it. Long live Fortran!

BeetleB 4y ago
> How much are software engineers judged by the code quality? And how much by the end results (shipped features/projects)? Many differences: 1. Everyone can tell if the SW is doing what it should. Ensuring correctness in the long run can lead to seeing gains in maintaining code quality. With a lot of scientific output, many people will just trust the output of the program. Crappy code quality is not easy to perceive. 2. In many code bases, backwards compatibility is important. Hopefully you'll have many users. With most scientific computation code bases, the user base is tiny (often 1). So no one cares if you break something when you add a feature. Couple it with bullet 1 above, no one even notices if you broke something. With regular SW projects, the need for backwards compatibility can once again drive good SW practices. I'm not saying all Fortran programmers are bad. Just that it is very tolerant of bad ones, and so they are highly overrepresented. > I'm happy we have stable libraries for it. As someone who couldn't stomach Fortran, as far as numerical work goes, plenty of other languages can utilize those same libraries. Having stable numerical libraries is not unique to Fortran. In fact, a colleague wasted way too much time during his PhD taking his group's 40K Fortran code base and porting it to C++.
- robocat 4y ago
  > Everyone can tell if the SW is doing what it should I am not sure that would be a majority opinion. Robocat’s Law: software complexity increases until it can’t be understood by anybody. > Fortran code base and porting it to C++ I once tried to counsel a PhD friend to use Mathematica to model their engineering problem, however instead she listened to other people in the civil engineering department to use C++, and she spent most of her time learning C++ and not enough time on her models.
  - lmm 4y ago
    > I am not sure that would be a majority opinion. Robocat’s Law: software complexity increases until it can’t be understood by anybody. Plenty of banks don't understand how their software works. But they can see that at the end of the day it calculates the right amount of money. (If it doesn't, eventually the client complains, or eventually your manager complains, depending on which direction it was wrong in). For a lot of these scientific modelling systems there's no such sanity check.
tored 4y ago
> How much are software engineers judged by the code quality? Difference is of course that most software engineers work on some commercial project with relative little effect on the world politics, and not bleeding edge science that affects current world politics, thus it ought be higher requirements for scientific computing than commercial computing.

BeetleB 4y ago

> How much are software engineers judged by the code quality? And how much by the end results (shipped features/projects)? Many differences: 1. Everyone can tell if the SW is doing what it should. Ensuring correctness in the long run can lead to seeing gains in maintaining code quality. With a lot of scientific output, many people will just trust the output of the program. Crappy code quality is not easy to perceive. 2. In many code bases, backwards compatibility is important. Hopefully you'll have many users. With most scientific computation code bases, the user base is tiny (often 1). So no one cares if you break something when you add a feature. Couple it with bullet 1 above, no one even notices if you broke something. With regular SW projects, the need for backwards compatibility can once again drive good SW practices. I'm not saying all Fortran programmers are bad. Just that it is very tolerant of bad ones, and so they are highly overrepresented. > I'm happy we have stable libraries for it. As someone who couldn't stomach Fortran, as far as numerical work goes, plenty of other languages can utilize those same libraries. Having stable numerical libraries is not unique to Fortran. In fact, a colleague wasted way too much time during his PhD taking his group's 40K Fortran code base and porting it to C++.

robocat 4y ago
> Everyone can tell if the SW is doing what it should I am not sure that would be a majority opinion. Robocat’s Law: software complexity increases until it can’t be understood by anybody. > Fortran code base and porting it to C++ I once tried to counsel a PhD friend to use Mathematica to model their engineering problem, however instead she listened to other people in the civil engineering department to use C++, and she spent most of her time learning C++ and not enough time on her models.
- lmm 4y ago
  > I am not sure that would be a majority opinion. Robocat’s Law: software complexity increases until it can’t be understood by anybody. Plenty of banks don't understand how their software works. But they can see that at the end of the day it calculates the right amount of money. (If it doesn't, eventually the client complains, or eventually your manager complains, depending on which direction it was wrong in). For a lot of these scientific modelling systems there's no such sanity check.

tored 4y ago

> How much are software engineers judged by the code quality? Difference is of course that most software engineers work on some commercial project with relative little effect on the world politics, and not bleeding edge science that affects current world politics, thus it ought be higher requirements for scientific computing than commercial computing.