4 ms·

So, that code gets me thinking about premature optimization. In the "verschlimmbessern born of optimizing the wrong thing because you didn't use measurement to

So, that code gets me thinking about premature optimization. In the "verschlimmbessern born of optimizing the wrong thing because you didn't use measurement to guide your efforts" sense. The rule of thumb I hear is that, in a mature product, reading and maintaining code takes about 10 times as much effort as writing it in the first place. I've never tried to measure this myself, but it doesn't seem to be wildly off from what I see at work, so let's go with it. Let's also assume, for the sake of argument, that these AI tools double the productivity of people writing new code. Or, equivalently, they halve the time it takes to write it. (This is a lot more than what I see people typically claim, but I'm trying to steelman and also it makes the math easier.) Anyway, this would imply that, speaking purely in terms of raw productivity (not, say, security or correctness) the AI coding assistant is a net win when the code that's written using it is less than 5% more difficult to maintain. And I'm inclined to think that, if Copilot & friends are enabling more people to write more code that looks like what we see in this article (also not wildly off from what I see at work), then it's hard to see how they could possibly be making codebases where they are used less than 5% more expensive to maintain.

david-gpu 2y ago
Can you elaborate on this part? I am trying to understand. > in a mature product, reading and maintaining code takes about 10 times as much effort as writing it in the first place Wouldn't that imply that rewriting a mature codebase from scratch would take ten times less effort than reading and maintaining it? I only saw two instances where (different) management approved a complete rewrite of a working product and in both cases it turned out to be a disaster, because it is easy to severely underestimate how much effort it will take to match the features, quality and performance of the old codebase. I suspect it is almost universally better to refactor the old codebase incrementally. Based on that, I take that you mean something else and I didn't get your point.
- dartos 2y ago
  OP said “writing it in the first place” not “rewriting” But I agree that their numbers don’t really make sense. Software dev is hard to quantify like that.
  - david-gpu 2y ago
    > OP said “writing it in the first place” not “rewriting” They did, but how is that significantly different?
    - addaon 2y ago
      Every line of code in the first implementation is there for a reason -- it has an implicit history, and implements a requirement. If that requirement is not captured elsewhere, then the prerequisite for /re/writing a system is to read the first implementation, understand the implicit requirements in the code, capture those requirements (or explicitly eliminate them if incorrect), and /then/ start writing version two. So /re/writing a system is a strict superset of both reading a previous implementation and implementing, and is thus harder than either.
      - dartos 2y ago
        Very well put
      - mumblemumble 2y ago
        True. That said in any non-trivial project, writing in the first place and rewriting aren't too different from each other in practice. Assuming someone doesn't have the ability to maintain a consistent and always-accurate mental map of tens of thousands of lines of code, most of which they probably didn't write themself and some of which they might have never actually looked at before, they're going to very rapidly reach a point where most of the work involved in adding a new feature consists of reading existing code to understand how it behaves and how the new code needs to interact with it. So the expensive part of adding new code to a work in progress, and the expensive part of rewriting existing code, are more-or-less one and the same.
      - david-gpu 2y ago
        > So /re/writing a system is a strict superset of both reading a previous implementation and implementing, and is thus harder than either. As you said, every line in the old product had a reason to be. You can learn that reason in two ways: the way it was done in the first place, or by analyzing the old code. My argument is that the amount of effort required in both cases is in the same ballpark -- it will depend on a number of factors such as the quality and quantity of the documentation and testing in the old product, the availability of people who worked on the first product, etc. So, no, rewriting a system is not automatically more work than writing the original one. But it is certainly not automatically less work either, and many people make the incorrect assumption that rewriting a system is going to take much less work than fixing the existing one.
- zare_st 2y ago
  Absolutely no. If a line of code belongs in a project with one file and a main() function, the presumption of impact of that code line on overall code paths is trivial. If that line of code belongs in a library procedure used by a million LOC project, presumption cannot be done if you don't the project internals and tooling. Rewriting entire systems or frameworks because one thinks that it's hard to implement a certain class of features is almost always a recipe for disaster.

david-gpu 2y ago

Can you elaborate on this part? I am trying to understand. > in a mature product, reading and maintaining code takes about 10 times as much effort as writing it in the first place Wouldn't that imply that rewriting a mature codebase from scratch would take ten times less effort than reading and maintaining it? I only saw two instances where (different) management approved a complete rewrite of a working product and in both cases it turned out to be a disaster, because it is easy to severely underestimate how much effort it will take to match the features, quality and performance of the old codebase. I suspect it is almost universally better to refactor the old codebase incrementally. Based on that, I take that you mean something else and I didn't get your point.

dartos 2y ago
OP said “writing it in the first place” not “rewriting” But I agree that their numbers don’t really make sense. Software dev is hard to quantify like that.
- david-gpu 2y ago
  > OP said “writing it in the first place” not “rewriting” They did, but how is that significantly different?
  - addaon 2y ago
    Every line of code in the first implementation is there for a reason -- it has an implicit history, and implements a requirement. If that requirement is not captured elsewhere, then the prerequisite for /re/writing a system is to read the first implementation, understand the implicit requirements in the code, capture those requirements (or explicitly eliminate them if incorrect), and /then/ start writing version two. So /re/writing a system is a strict superset of both reading a previous implementation and implementing, and is thus harder than either.
    - dartos 2y ago
      Very well put
    - mumblemumble 2y ago
      True. That said in any non-trivial project, writing in the first place and rewriting aren't too different from each other in practice. Assuming someone doesn't have the ability to maintain a consistent and always-accurate mental map of tens of thousands of lines of code, most of which they probably didn't write themself and some of which they might have never actually looked at before, they're going to very rapidly reach a point where most of the work involved in adding a new feature consists of reading existing code to understand how it behaves and how the new code needs to interact with it. So the expensive part of adding new code to a work in progress, and the expensive part of rewriting existing code, are more-or-less one and the same.
    - david-gpu 2y ago
      > So /re/writing a system is a strict superset of both reading a previous implementation and implementing, and is thus harder than either. As you said, every line in the old product had a reason to be. You can learn that reason in two ways: the way it was done in the first place, or by analyzing the old code. My argument is that the amount of effort required in both cases is in the same ballpark -- it will depend on a number of factors such as the quality and quantity of the documentation and testing in the old product, the availability of people who worked on the first product, etc. So, no, rewriting a system is not automatically more work than writing the original one. But it is certainly not automatically less work either, and many people make the incorrect assumption that rewriting a system is going to take much less work than fixing the existing one.
zare_st 2y ago
Absolutely no. If a line of code belongs in a project with one file and a main() function, the presumption of impact of that code line on overall code paths is trivial. If that line of code belongs in a library procedure used by a million LOC project, presumption cannot be done if you don't the project internals and tooling. Rewriting entire systems or frameworks because one thinks that it's hard to implement a certain class of features is almost always a recipe for disaster.