6 ms·

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 b

by 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.
    - JohnFen 4y ago
      Oh, yes, I agree with this. But I count this more as "research" than creating production code.
  - whstl 4y ago
    I've "rewrote" a lot of code in my career. I'm putting "rewrote" in quotes, because it was sometimes porting from unmaintained programs in obsolete platforms to something more modern (sometimes without even being able to run them), and other times by doing large-scale refactoring that left the codebase almost unrecognizable. While I agree with #1, that "offensive" code is offensive for a reason (no time, no experience, no tooling, no hindsight), I don't really agree with point #2. With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing. IMO: bad code is often due to accidental complexity, often brought in by the programmers themselves. And very rarely due to essential complexity.
    - JohnFen 4y ago
      Your examples are excellent reasons to do a rewrite. Rewriting code is not always the wrong decision. But in the main, when it seems that a rewrite is warranted, it's a good idea to think long, hard, and objectively about why it seems like a good idea. > With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing. You're right. I should have been more expansive. The rewrite may not reproduce the same issue (although the odds are good you'll see what the issue was!), but it will have its own issues, and is also likely to eventually also become "offensive" code that a future dev will have the urge to rewrite. I use the word "offensive" here in a technical sense, not in a judgmental sense. Great code can become offensive with time as requirements, environments, and development methodologies change. The main thing is that rewriting code is very expensive in both the monetary and risk sense. In the end, it's a question of cost/benefit. If the benefit of a rewrite is less than the cost, then rewriting is the wrong decision. > bad code is often due to accidental complexity, often brought in by the programmers themselves. Yes, I agree. And the majority of it turned out bad because of maintenance. Too much duct tape and bubble gum has accumulated over time.
sharemywin 4y ago
You both are providing a wonderful example of: "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. "

by z3t4 4y ago

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.
  - JohnFen 4y ago
    Oh, yes, I agree with this. But I count this more as "research" than creating production code.
- whstl 4y ago
  I've "rewrote" a lot of code in my career. I'm putting "rewrote" in quotes, because it was sometimes porting from unmaintained programs in obsolete platforms to something more modern (sometimes without even being able to run them), and other times by doing large-scale refactoring that left the codebase almost unrecognizable. While I agree with #1, that "offensive" code is offensive for a reason (no time, no experience, no tooling, no hindsight), I don't really agree with point #2. With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing. IMO: bad code is often due to accidental complexity, often brought in by the programmers themselves. And very rarely due to essential complexity.
  - JohnFen 4y ago
    Your examples are excellent reasons to do a rewrite. Rewriting code is not always the wrong decision. But in the main, when it seems that a rewrite is warranted, it's a good idea to think long, hard, and objectively about why it seems like a good idea. > With enough hindsight and careful study, it is entirely possible to avoid the offensive characteristics while doing the same thing. You're right. I should have been more expansive. The rewrite may not reproduce the same issue (although the odds are good you'll see what the issue was!), but it will have its own issues, and is also likely to eventually also become "offensive" code that a future dev will have the urge to rewrite. I use the word "offensive" here in a technical sense, not in a judgmental sense. Great code can become offensive with time as requirements, environments, and development methodologies change. The main thing is that rewriting code is very expensive in both the monetary and risk sense. In the end, it's a question of cost/benefit. If the benefit of a rewrite is less than the cost, then rewriting is the wrong decision. > bad code is often due to accidental complexity, often brought in by the programmers themselves. Yes, I agree. And the majority of it turned out bad because of maintenance. Too much duct tape and bubble gum has accumulated over time.

sharemywin 4y ago

You both are providing a wonderful example of: "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. "