28 ms·

So that you will never see wether the code is actually maintainable or not? You have described a strategy to avoid having to deal with bad maintainability, not

by usrusr 10y ago

So that you will never see wether the code is actually maintainable or not? You have described a strategy to avoid having to deal with bad maintainability, not a strategy to avoid creating bad maintainability.

barryhoodlum 10y ago
That's the joke!
js8 10y ago
Quite clearly, I was being sarcastic. In fact, on three different points: 1. I see "unmaintainable" as mostly a factor of time (or age of the codebase), of changing requirements and people working on the code. So giving advice on how to write the code to be maintainable isn't gonna help much. If people turnover quickly, they won't bother, if they turnover slower, they will do their best to keep it maintainable and yet fail. 2. People who follow (intentionally or not) the advice I gave only ever see maintainable code, so from their perspective, it leads to (having to deal with) maintainable code. 3. (= 1. + 2.) Sadly, the people who are the most displeased with the legacy code not being maintainable are the ones who tend to leave quickly (or write something on their own), paradoxically, compounding to the problem of the unmaintainable code in the first place! I don't think there is a good solution to the problem. Maintaining old code is hard work.
- usrusr 10y ago
  Ok, I see it now, but the liberal conflation of "maintainable" and "code that is easy to work on" that is repeated in 2. still hurts my eyes: they don't see maintainable code, they see code that is easy to work on - not because it is maintainable, but because of its position in the code lifecycle. The confusion between these two is exactly your point, sure, but I don't know how to say it better, I think your wording is just too close to subscribing to it yourself. They think they see maintainable code. I know I do, while writing what I will later call a hopeless mess. (Written by someone who has been doing brownfield projects, often bordering on code archeology, at the same employer for far too many years)
  - js8 10y ago
    Not really sure what your objection is; what exactly difference you see between "maintainable" and "easy to work on"? Could it be that a good definition of maintainable is simply "easy to understand by others"? Then, of course, code earlier in the life cycle tends to be easier to understand. Then there could be a difference between "easy to work with" (by the original author(s)) and "easy to understand by others". But assuming original authors were good programmers, I am not sure how they could cause this difference to occur.
yxhuvud 10y ago
Having seen more than one code base is a good way to learn good and maintainable ways to write code though, so that part is still decent advice. Avoiding maintenance task of legacy apps is pretty silly though..

by usrusr 10y ago

barryhoodlum 10y ago

That's the joke!

js8 10y ago

Quite clearly, I was being sarcastic. In fact, on three different points: 1. I see "unmaintainable" as mostly a factor of time (or age of the codebase), of changing requirements and people working on the code. So giving advice on how to write the code to be maintainable isn't gonna help much. If people turnover quickly, they won't bother, if they turnover slower, they will do their best to keep it maintainable and yet fail. 2. People who follow (intentionally or not) the advice I gave only ever see maintainable code, so from their perspective, it leads to (having to deal with) maintainable code. 3. (= 1. + 2.) Sadly, the people who are the most displeased with the legacy code not being maintainable are the ones who tend to leave quickly (or write something on their own), paradoxically, compounding to the problem of the unmaintainable code in the first place! I don't think there is a good solution to the problem. Maintaining old code is hard work.

usrusr 10y ago
Ok, I see it now, but the liberal conflation of "maintainable" and "code that is easy to work on" that is repeated in 2. still hurts my eyes: they don't see maintainable code, they see code that is easy to work on - not because it is maintainable, but because of its position in the code lifecycle. The confusion between these two is exactly your point, sure, but I don't know how to say it better, I think your wording is just too close to subscribing to it yourself. They think they see maintainable code. I know I do, while writing what I will later call a hopeless mess. (Written by someone who has been doing brownfield projects, often bordering on code archeology, at the same employer for far too many years)
- js8 10y ago
  Not really sure what your objection is; what exactly difference you see between "maintainable" and "easy to work on"? Could it be that a good definition of maintainable is simply "easy to understand by others"? Then, of course, code earlier in the life cycle tends to be easier to understand. Then there could be a difference between "easy to work with" (by the original author(s)) and "easy to understand by others". But assuming original authors were good programmers, I am not sure how they could cause this difference to occur.

yxhuvud 10y ago

Having seen more than one code base is a good way to learn good and maintainable ways to write code though, so that part is still decent advice. Avoiding maintenance task of legacy apps is pretty silly though..