5 ms·

I quit my last job because my team was in this room spiral. And management's solution to the problem? Work harder. As far as I know, everyone else still works

I quit my last job because my team was in this room spiral. And management's solution to the problem? Work harder. As far as I know, everyone else still works there. I bet some of them sleep at their desks trying to keep adding more knots to that awful legacy system. And it didn't get that way WHILE I was there. That project had been around since 1998. They were so afraid of change that they were still using the C++98 compiler. So I didn't even leave that job with relevant (read modern) C++ knowledge. Funny thing: The server architect at my current job was one of the founding members on that project. He had the same kind of view towards it. I feel like that project has been in a doom spiral from the beginning. So 21 years at this point. It blows my mind that there are these legacy code sweat shops out there barely holding software together like this. What a miserable existence.

romwell 7y ago
>And it didn't get that way WHILE I was there. That project had been around since 1998. They were so afraid of change that they were still using the C++98 compiler. So I didn't even leave that job with relevant (read modern) C++ knowledge. This happened to me too! I understand the reasons for that: it was highly specialized (scientific) software used in computer chip manufacturing. Most of the people on the team had a PhD in Engineering or Science, but few had extensive Computer Science training before joining the company. The hardware industry is moving slowly, because you don't just upgrade a fab. Some of the clients were on RH5, so that was our build target. Part of the codebase was in Fortran (and for good reasons too; this language is common in HPC/scientific scene). All this resulted in a codebase that was part brilliant, part byzantine, poorly documented, and not even compiling with a modern C++ compiler (hence reluctance to start using C++11 or newer). Thankfully, the automated test suite was holding it all together; but that was about it. As people left, they took systems knowledge with them that was written down nowhere, and nobody wanted to do a deep dive and document the still known parts. Predictably, the priority has shifted to "quality" - that is, fixing bugs instead of innovating on the core functionality. That was not the only reasons why I left for better opportunities, but it was a big factor. It wasn't the legacy system that was scary - no more scary than a hairy prototype that gets the job done, really - it's that nobody was going to put in the effort and take the risk to start moving from a decades-old "prototype" stage. I believe that things finally started moving when the people there realized that there is no way but forward; I hope they are using modern C++ now. But that train was set in motion after I left.
- rocqua 7y ago
  This sounds a lot like the stories I have heard coming from ASML. Especially the part of people with a PhD in engineering writing code.
- BlueTemplar 7y ago
  Isn't "modern C++" pretty much an oxymoron, and pretty much follows the above definition of "legacy software" ?
  - romwell 7y ago
    It's.. not? The definition of "legacy software" in this discussion is: software that grew so many "temporary" fixes and workarounds instead of necessary architectural changes that it's in permanent maintenance mode, and entire parts of it are untouchable because nobody understands what they do due to the exponential increase in complexity stemming from the abundance of these hacks, exacerbated by system knowledge evaporating with engineer turnover. That doesn't apply to either C++ language and compiler (rapidly evolving in the past decade), nor projects written in it, generally (that's not a property of the language). On that note, we've integrated some Fortran code that was written in the 80s that I wouldn't call "legacy" under this definition: the algorithm was clear, and the implementation documented well enough that modifying it, if necessary, would not have been hard, and using it with our floor was very simple (it was one of the flavors of gradient descent algorithms that converged much better than several others).
    - BlueTemplar 7y ago
      > software that grew so many "temporary" fixes and workarounds instead of necessary architectural changes that it's in permanent maintenance mode, and entire parts of it are untouchable because nobody understands what they do due to the exponential increase in complexity stemming from the abundance of these hacks, exacerbated by system knowledge evaporating with engineer turnover Pretty much this, what else am I supposed to think when I read this : ? https://stackoverflow.com/questions/17103925/how-well-is-unicode-supported-in-c11 https://stackoverflow.com/questions/17103925/how-well-is-uni... We aren't on the ARPANet anymore - I'm expecting even low-level programming languages to use native Unicode. The way how C equates "char" to both character and byte is fundamentally broken. (This is also/more(?) an issue with Unicode - IMHO we should have increased byte size to something like 32 bits (during the transition to 64-bit words ?) to be able to fit one character per byte - the increased hardware cost for text storage would have been quickly compensated by the decrease in developer costs. But here we are.)
anovikov 7y ago
On the good side of things, their business must be doing really great because they have money to support that monstrosity, and have motivation to, meaning: it gives them a lot of cash.

romwell 7y ago

>And it didn't get that way WHILE I was there. That project had been around since 1998. They were so afraid of change that they were still using the C++98 compiler. So I didn't even leave that job with relevant (read modern) C++ knowledge. This happened to me too! I understand the reasons for that: it was highly specialized (scientific) software used in computer chip manufacturing. Most of the people on the team had a PhD in Engineering or Science, but few had extensive Computer Science training before joining the company. The hardware industry is moving slowly, because you don't just upgrade a fab. Some of the clients were on RH5, so that was our build target. Part of the codebase was in Fortran (and for good reasons too; this language is common in HPC/scientific scene). All this resulted in a codebase that was part brilliant, part byzantine, poorly documented, and not even compiling with a modern C++ compiler (hence reluctance to start using C++11 or newer). Thankfully, the automated test suite was holding it all together; but that was about it. As people left, they took systems knowledge with them that was written down nowhere, and nobody wanted to do a deep dive and document the still known parts. Predictably, the priority has shifted to "quality" - that is, fixing bugs instead of innovating on the core functionality. That was not the only reasons why I left for better opportunities, but it was a big factor. It wasn't the legacy system that was scary - no more scary than a hairy prototype that gets the job done, really - it's that nobody was going to put in the effort and take the risk to start moving from a decades-old "prototype" stage. I believe that things finally started moving when the people there realized that there is no way but forward; I hope they are using modern C++ now. But that train was set in motion after I left.

rocqua 7y ago
This sounds a lot like the stories I have heard coming from ASML. Especially the part of people with a PhD in engineering writing code.
BlueTemplar 7y ago
Isn't "modern C++" pretty much an oxymoron, and pretty much follows the above definition of "legacy software" ?
- romwell 7y ago
  It's.. not? The definition of "legacy software" in this discussion is: software that grew so many "temporary" fixes and workarounds instead of necessary architectural changes that it's in permanent maintenance mode, and entire parts of it are untouchable because nobody understands what they do due to the exponential increase in complexity stemming from the abundance of these hacks, exacerbated by system knowledge evaporating with engineer turnover. That doesn't apply to either C++ language and compiler (rapidly evolving in the past decade), nor projects written in it, generally (that's not a property of the language). On that note, we've integrated some Fortran code that was written in the 80s that I wouldn't call "legacy" under this definition: the algorithm was clear, and the implementation documented well enough that modifying it, if necessary, would not have been hard, and using it with our floor was very simple (it was one of the flavors of gradient descent algorithms that converged much better than several others).
  - BlueTemplar 7y ago
    > software that grew so many "temporary" fixes and workarounds instead of necessary architectural changes that it's in permanent maintenance mode, and entire parts of it are untouchable because nobody understands what they do due to the exponential increase in complexity stemming from the abundance of these hacks, exacerbated by system knowledge evaporating with engineer turnover Pretty much this, what else am I supposed to think when I read this : ? https://stackoverflow.com/questions/17103925/how-well-is-unicode-supported-in-c11 https://stackoverflow.com/questions/17103925/how-well-is-uni... We aren't on the ARPANet anymore - I'm expecting even low-level programming languages to use native Unicode. The way how C equates "char" to both character and byte is fundamentally broken. (This is also/more(?) an issue with Unicode - IMHO we should have increased byte size to something like 32 bits (during the transition to 64-bit words ?) to be able to fit one character per byte - the increased hardware cost for text storage would have been quickly compensated by the decrease in developer costs. But here we are.)

anovikov 7y ago

On the good side of things, their business must be doing really great because they have money to support that monstrosity, and have motivation to, meaning: it gives them a lot of cash.