5 ms·

And the problem our industry has is that these concepts are not well-defined. You can easily have engineer A strongly claim that the code that was put in front

And the problem our industry has is that these concepts are not well-defined. You can easily have engineer A strongly claim that the code that was put in front of them from engineer B is terribly designed and will be unmaintainable and then they write an alternative proposal that they love, and then the next guy C comes with the exact criticism of the alternative, and the twist is that C is actually B, the guy who wrote the originally criticized code. You can watch this kind of stuff first hand here in HN discussions. It's so sad, it's actually pretty comical again if you are not vested in it.

highwaylights 4y ago
The solution is D, which means we come up with a methodology that solves problems A-C and then mandate that everyone sticks to it. And now we have problems A through E.
- letitbeirie 4y ago
  Oblig: https://xkcd.com/927/ https://xkcd.com/927/
  - haweemwho 4y ago
    [flagged]
z3t4 4y ago
The solution is that the one who write the software/architecture is also the one maintaining it. When it comes to writing easy to maintain code, that can only be learned by maintaining code for a long time. If that dude leaves the team and you have no one that can edit it, just rewrite the code from scratch! So you basically want to follow the Unix philosophy or micro service architecture. This allows you to hire any kind of programmer, you no longer need to find someone experienced in programming language X, with frameworks Y for platform Z (which is impossible), you can hire anyone that is experience enough to do the work and let him/her write the software in whatever environment he/she pleases.
- aetherson 4y ago
  "Rewrite from scratch everything that engineer X touched in four years of working here after he leaves" does not sound like a feasible approach to development. Also, while having good code separation between contractual APIs is a good goal and worth pushing towards, the idea that nobody would ever have shared ownership of any code unit between API contracts is too extreme.
  - z3t4 4y ago
    You should not rewrite something that works, only when you need to make larger changes, even if the guy who wrote the program is still there you might want to rewrite from scratch if the requirements change, like you now need to handle 100x more traffic and need to have something with better performance, or scaled out.
    - withinboredom 4y ago
      SOLID principles at work. Closed for modification. If you’re modifying it, you’re not doing SOLID programming. /s
  - JohnFen 4y ago
    "Rewrite it" is almost always the wrong answer, although it can be an overpowering instinct. Personally, through decades of experience, I've learned that when this impulse hits me, I need to consciously remind myself of these truths: 1) The engineer(s) that wrote the offensive code were almost certainly not idiots. The code is probably that way for a reason, even if that reason isn't obvious to me. 2) If I embark on rewriting it "correctly", the odds are very good that I will learn why the code was as it was in the first place, and my rewrite will undoubtedly have my own style, but will not likely avoid whatever issue it was that made me think it should be rewritten.
    - convolvatron 4y ago
      I find value in rewriting/refactoring it as a learning exercise. just take a quick pass. now you are in a really good position to talk about what the strengths and weaknesses are of the existing version.
Terretta 4y ago
> You can watch this kind of stuff first hand... Something something memory allocating llamas cough.
wpietri 4y ago
I get what you're saying, but I don't good definitions are the problem. Whether an architecture is objectively excellent doesn't really matter. The question is whether the people who are going to maintain the thing can work well with it. A tribe of OO partisans will produce a very different system than a tribe of FP ones. Each could find their own system highly maintainable but find the others' incomprehensible enough that they'd rather rebuild it than take it over. What I think really matters is close, respectful collaboration among a group of people in a context with frequent iteration, so that the team can learn to make good choices together. And, over the longer term, enough continuity in that team so that new people can absorb enough context that the culture is transmitted for as long as the code lasts.
- deleted 4y ago
  [deleted]

highwaylights 4y ago

The solution is D, which means we come up with a methodology that solves problems A-C and then mandate that everyone sticks to it. And now we have problems A through E.

letitbeirie 4y ago
Oblig: https://xkcd.com/927/ https://xkcd.com/927/
- haweemwho 4y ago
  [flagged]

z3t4 4y ago

The solution is that the one who write the software/architecture is also the one maintaining it. When it comes to writing easy to maintain code, that can only be learned by maintaining code for a long time. If that dude leaves the team and you have no one that can edit it, just rewrite the code from scratch! So you basically want to follow the Unix philosophy or micro service architecture. This allows you to hire any kind of programmer, you no longer need to find someone experienced in programming language X, with frameworks Y for platform Z (which is impossible), you can hire anyone that is experience enough to do the work and let him/her write the software in whatever environment he/she pleases.

aetherson 4y ago
"Rewrite from scratch everything that engineer X touched in four years of working here after he leaves" does not sound like a feasible approach to development. Also, while having good code separation between contractual APIs is a good goal and worth pushing towards, the idea that nobody would ever have shared ownership of any code unit between API contracts is too extreme.
- z3t4 4y ago
  You should not rewrite something that works, only when you need to make larger changes, even if the guy who wrote the program is still there you might want to rewrite from scratch if the requirements change, like you now need to handle 100x more traffic and need to have something with better performance, or scaled out.
  - withinboredom 4y ago
    SOLID principles at work. Closed for modification. If you’re modifying it, you’re not doing SOLID programming. /s
- JohnFen 4y ago
  "Rewrite it" is almost always the wrong answer, although it can be an overpowering instinct. Personally, through decades of experience, I've learned that when this impulse hits me, I need to consciously remind myself of these truths: 1) The engineer(s) that wrote the offensive code were almost certainly not idiots. The code is probably that way for a reason, even if that reason isn't obvious to me. 2) If I embark on rewriting it "correctly", the odds are very good that I will learn why the code was as it was in the first place, and my rewrite will undoubtedly have my own style, but will not likely avoid whatever issue it was that made me think it should be rewritten.
  - convolvatron 4y ago
    I find value in rewriting/refactoring it as a learning exercise. just take a quick pass. now you are in a really good position to talk about what the strengths and weaknesses are of the existing version.

Terretta 4y ago

> You can watch this kind of stuff first hand... Something something memory allocating llamas cough.

wpietri 4y ago

I get what you're saying, but I don't good definitions are the problem. Whether an architecture is objectively excellent doesn't really matter. The question is whether the people who are going to maintain the thing can work well with it. A tribe of OO partisans will produce a very different system than a tribe of FP ones. Each could find their own system highly maintainable but find the others' incomprehensible enough that they'd rather rebuild it than take it over. What I think really matters is close, respectful collaboration among a group of people in a context with frequent iteration, so that the team can learn to make good choices together. And, over the longer term, enough continuity in that team so that new people can absorb enough context that the culture is transmitted for as long as the code lasts.

deleted 4y ago
[deleted]