4 ms·

Every code base I have ever worked on was a legacy nightmare. Every "greenfield" project I joined turned into a legacy nightmare within weeks. I have never enco

Every code base I have ever worked on was a legacy nightmare. Every "greenfield" project I joined turned into a legacy nightmare within weeks. I have never encountered enjoyable code. I had the displeasure of wading through Spring, Hibernate and Apache HTTP client code before and they were all an incomprehensible mess. My conclusion: You know the claim "any medication that really has an effect must also have side effects". I would like to adapt that for code: Any code that does a lot of useful and complex things must be an arcane, barely maintainable mess that can only be understood by deep study.

alex_suzuki 2y ago
IMHO library code is especially challenging, as cruft has a tendency to accumulate, historical behavior needs to be preserved, and APIs are set in stone once they’re built.
lukan 2y ago
"Any code that does a lot of useful and complex things must be an arcane, barely maintainable mess that can only be understood by deep study." "Every code base I have ever worked on was a legacy nightmare. Every "greenfield" project I joined turned into a legacy nightmare within weeks" I am sorry to say this, but it really sounds like you were either really, really unlucky, or part of the reason why it became a mess. Complicated things are complicated. Nothing can ever change that and it requires study to understand it. But it still does matter a lot, how one organizes the whole thing. How it is structured, documented(!), refactored. Are there competent people in charge who understand it all and kick peoples asses if they make even a temporary mess or forget to document, or do random people make changes wherever they see fit, because a deadline is ticking? Modularisation is usually the key. Small modules do one thing and are as seperated as much as possible with as little side effects as possible. And if one has to ship things, it is not always possible to keep it pure and if the code is not intended to live forever then this is often fine. But if the codebase is supposed to stay, then there needs to be the time to clean up the hacks. Or don't and then you end up scared touching anything. That being said, the technologies you mentioned, I would not like to touch either..
- t43562 2y ago
  I think that's a bit cruel. Usually mess happens because lots of people with different ideas about the future needs and best structure meet up in the code - and it's hard to develop a consistent culture. Also codebases get too large for any one person to refactor them into shape in the time they have each day. So you end up needing people who are responsible just for keeping things in shape.
  - lukan 2y ago
    Well, that is why I said with those words it sounds like this to me, not that he or she was in fact responsible. (at least this is what I meant) "Also codebases get too large for any one person to refactor them into shape in the time they have each day." Which is why modules, or subprojects were invented. Or however you want to call it, if one person is only responsible for a small part and not everyone for everything. And yes, there is also the non trivial problem of time management.
    - t43562 2y ago
      yup, but the style of the modules starts to diverge as different people maintain them. IMO one does want people whose fulltime job is to looking at a codebase orthogonally to those who are just implementing a feature. People who make sure it builds fast, is secure tries to be consistent to some degree etc. Many companies call teams/indivuduals like this a "cost centre" and disparage it because they are dolts.
      - lukan 2y ago
        If those code checkers are experienced programmers, who do not annoy people with arbitary guidelines and standards, then yes, this might also work. But I do not think they are always necessary as a seperate full time role, if everything works normal otherwise. And with working normal, I mean there is enough time to refactor and document and clean up and is actually done.
- RangerScience 2y ago
mrweasel 2y ago
Something in your answer triggered a flash back to when I worked for a phone company, 20 years ago. One team, under the leadership of our questionable chief architect, had produced our new, all encompassing backend system. This was to be the corner stone of all future development and integration, dog slow and complicated as it where. I worked as a .Net developer and had the misfortune to be among the first to integrate with this monster. Try as I might, I could not get .Net to interoperate with these services. Finally I figured out that the SOAP services was using some old deprecated versions. Going back to the architect, I ask "did you build this on Apache Axis, and please say Axis2", but no, it was just Axis, a deprecated version, that would generate webservices not supported by newer .Net version. That wasn't an problem, because: "None of our project have upgraded to those .Net versions yet"... DUDE, we've launched a brand new system based on that .Net version a year ago, and what was you f-ing plan for the future, to redo every single service using Axis2? This guy had based a brand new system on a framework/library that was no longer maintained, even before the system was launched.

alex_suzuki 2y ago

IMHO library code is especially challenging, as cruft has a tendency to accumulate, historical behavior needs to be preserved, and APIs are set in stone once they’re built.

lukan 2y ago

"Any code that does a lot of useful and complex things must be an arcane, barely maintainable mess that can only be understood by deep study." "Every code base I have ever worked on was a legacy nightmare. Every "greenfield" project I joined turned into a legacy nightmare within weeks" I am sorry to say this, but it really sounds like you were either really, really unlucky, or part of the reason why it became a mess. Complicated things are complicated. Nothing can ever change that and it requires study to understand it. But it still does matter a lot, how one organizes the whole thing. How it is structured, documented(!), refactored. Are there competent people in charge who understand it all and kick peoples asses if they make even a temporary mess or forget to document, or do random people make changes wherever they see fit, because a deadline is ticking? Modularisation is usually the key. Small modules do one thing and are as seperated as much as possible with as little side effects as possible. And if one has to ship things, it is not always possible to keep it pure and if the code is not intended to live forever then this is often fine. But if the codebase is supposed to stay, then there needs to be the time to clean up the hacks. Or don't and then you end up scared touching anything. That being said, the technologies you mentioned, I would not like to touch either..

t43562 2y ago
I think that's a bit cruel. Usually mess happens because lots of people with different ideas about the future needs and best structure meet up in the code - and it's hard to develop a consistent culture. Also codebases get too large for any one person to refactor them into shape in the time they have each day. So you end up needing people who are responsible just for keeping things in shape.
- lukan 2y ago
  Well, that is why I said with those words it sounds like this to me, not that he or she was in fact responsible. (at least this is what I meant) "Also codebases get too large for any one person to refactor them into shape in the time they have each day." Which is why modules, or subprojects were invented. Or however you want to call it, if one person is only responsible for a small part and not everyone for everything. And yes, there is also the non trivial problem of time management.
  - t43562 2y ago
    yup, but the style of the modules starts to diverge as different people maintain them. IMO one does want people whose fulltime job is to looking at a codebase orthogonally to those who are just implementing a feature. People who make sure it builds fast, is secure tries to be consistent to some degree etc. Many companies call teams/indivuduals like this a "cost centre" and disparage it because they are dolts.
    - lukan 2y ago
      If those code checkers are experienced programmers, who do not annoy people with arbitary guidelines and standards, then yes, this might also work. But I do not think they are always necessary as a seperate full time role, if everything works normal otherwise. And with working normal, I mean there is enough time to refactor and document and clean up and is actually done.
RangerScience 2y ago

mrweasel 2y ago

Something in your answer triggered a flash back to when I worked for a phone company, 20 years ago. One team, under the leadership of our questionable chief architect, had produced our new, all encompassing backend system. This was to be the corner stone of all future development and integration, dog slow and complicated as it where. I worked as a .Net developer and had the misfortune to be among the first to integrate with this monster. Try as I might, I could not get .Net to interoperate with these services. Finally I figured out that the SOAP services was using some old deprecated versions. Going back to the architect, I ask "did you build this on Apache Axis, and please say Axis2", but no, it was just Axis, a deprecated version, that would generate webservices not supported by newer .Net version. That wasn't an problem, because: "None of our project have upgraded to those .Net versions yet"... DUDE, we've launched a brand new system based on that .Net version a year ago, and what was you f-ing plan for the future, to redo every single service using Axis2? This guy had based a brand new system on a framework/library that was no longer maintained, even before the system was launched.