4 ms·

Agreed until the very last sentence. Refactoring should never happen for its own sake. You should never make code beautiful because it's beautiful. It should be

Agreed until the very last sentence. Refactoring should never happen for its own sake. You should never make code beautiful because it's beautiful. It should be nice to the extent, as you correctly said, that it facilitates creating value, in form of a running program, not as source code. This means that refactoring is worth it exactly if the total time spent to refactor the code is less than the time you save implementing future features after the refactoring. I'm at the start of my career as a software engineer but it seems to me a good rule for refactoring is that it should only ever be done if the advantage can be evaluated in the form of concrete new features being easier to implement. If you refactor the code so that existing features would've felt nicer to implement, or are nicer to read, you've already played yourself, because maybe you get a high of ecstasy because the code that was ugly before is now clean, but as soon as the next feature comes around that you didn't anticipate, it was all for naught, and you're writing ugly code again.

josephg 4y ago
I’ve been programming for over 30 years and I don’t entirely agree with you. I agree that you should make choices in line with what will get the best long term value. Sometimes that long term value is captured by making dirty prototypes that you can learn from. But sometimes you’re working in a codebase which will probably outlive you. And in that case it often makes sense to think of your code base as a garden that you tend. Spending effort making tending the garden delightful will almost always pay off given enough time. And here I’m thinking about things like improving the build process to speed up compilation, adding tracing to make debugging easier, refactoring, documenting the core design and philosophy, and so on. You can’t make Google chrome, the Linux kernel, llvm, or other projects like that by taking dirty shortcuts every time you add a new feature. If you do, you’ll end up with a buggy, unmaintainable mess that is impossible to change without introducing new problems. This isn't just theoretical - look up the story of Toyota's brake problem a few years ago. I've also heard some grizzly stories about software practices at Boeing and Oracle. Good cooks clean their kitchens. Soldiers maintain their equipment. And efficient programmers keep tidy codebases.
- jagged-chisel 4y ago
  I'm with you. I tend to see little discussion about long term value. "Long term value" includes "making it less expensive to add features." At my current company, we would run in circles chasing the same bugs because of spaghetti code plus competing business requirements. The answer to "why do new features take so long?" was fairly straightforward. We were able to argue for a rewrite partially on the grounds of the speed of future enhancements. During the rewrite, it has been amazing to several team members (juniors, management) at how easy it is to track changing requirements when there's good infrastructure and when solutions are kept simple.
- Supermancho 4y ago
  > But sometimes you’re working in a codebase which will probably outlive you. This is so rare, it's not worth thinking about. Code lasts a decade or two before it's been completely rewritten or replaced. After 30 years, the oldest code that I ever touched exists in very few places (2 that I know of). > Spending effort making tending the garden delightful will almost always pay off given enough time. What constitutes "good practice" is ever-changing and it doesn't add business value. You work within the constraints of the time and move on. The people who do this find themselves in the best position, career-wise. Paying some small attention to maintenance helps you move up and on to bigger projects and responsibility. Like all things, pursue a middle ground of philosophy. ie You can fiddle with code forever trying to make it "better". More extensible, more maintainable, more clear, more more more. Arguing over future cases (premature planning) is the most common sin. Planning for everything to be reused is not being efficient. Regardless, you have biases that inform what you think is "better" and how software will be used, which future you (and other developers) will note share.
  - josephg 4y ago
    > Arguing over future cases (premature planning) is the most common sin.. There's definitely a scale between "unmaintainable mess" and "architecture astronomy" where both extremes are pathological. I've seen plenty of unmaintainable messes in my time - particularly from average teams who are lacking in good technical leadership. You see this sort of thing all the time in consulting, and in software teams at non-software companies. (Eg, in the airline industry). There's a reason why Martin Fowler talks a lot about software craftsmanship - because at places like Thoughtworks they could often use more of that sort of thinking. I've also seen plenty of overengineered messes too. Most smart college students (myself included) seem to need to go through this at some early point in our careers, where we really spread our wings and discover first hand why writing thousands of java classes is a terrible idea. (Or whatever the poison of the day is). If all your abstraction does is move your food (business logic / algorithms) around the plate, or -worse- hide it, then your abstraction is making the code worse. I have no idea which sin is more common. I think it really depends on what sort of engineers you spend time with. Google definitely suffers from the second kind of problem much more than the first - to the point where google (hilariously) often outsources making actual websites to external consulting companies, because their own software practices are too expensive to implement. Does your team need more long term thinking or more short term thinking? Its impossible to answer without reference to your actual team, your existing practices, and what you're trying to deliver. A weekend game jam should be scrappy, and the code for the space shuttle should be written carefully. Neither approach is objectively good or bad; there's just different tradeoffs appropriate for different kinds of project. The best senior programmers can switch style & philosophy based on whats needed for the task sitting right in front of them.

josephg 4y ago

I’ve been programming for over 30 years and I don’t entirely agree with you. I agree that you should make choices in line with what will get the best long term value. Sometimes that long term value is captured by making dirty prototypes that you can learn from. But sometimes you’re working in a codebase which will probably outlive you. And in that case it often makes sense to think of your code base as a garden that you tend. Spending effort making tending the garden delightful will almost always pay off given enough time. And here I’m thinking about things like improving the build process to speed up compilation, adding tracing to make debugging easier, refactoring, documenting the core design and philosophy, and so on. You can’t make Google chrome, the Linux kernel, llvm, or other projects like that by taking dirty shortcuts every time you add a new feature. If you do, you’ll end up with a buggy, unmaintainable mess that is impossible to change without introducing new problems. This isn't just theoretical - look up the story of Toyota's brake problem a few years ago. I've also heard some grizzly stories about software practices at Boeing and Oracle. Good cooks clean their kitchens. Soldiers maintain their equipment. And efficient programmers keep tidy codebases.

jagged-chisel 4y ago
I'm with you. I tend to see little discussion about long term value. "Long term value" includes "making it less expensive to add features." At my current company, we would run in circles chasing the same bugs because of spaghetti code plus competing business requirements. The answer to "why do new features take so long?" was fairly straightforward. We were able to argue for a rewrite partially on the grounds of the speed of future enhancements. During the rewrite, it has been amazing to several team members (juniors, management) at how easy it is to track changing requirements when there's good infrastructure and when solutions are kept simple.
Supermancho 4y ago
> But sometimes you’re working in a codebase which will probably outlive you. This is so rare, it's not worth thinking about. Code lasts a decade or two before it's been completely rewritten or replaced. After 30 years, the oldest code that I ever touched exists in very few places (2 that I know of). > Spending effort making tending the garden delightful will almost always pay off given enough time. What constitutes "good practice" is ever-changing and it doesn't add business value. You work within the constraints of the time and move on. The people who do this find themselves in the best position, career-wise. Paying some small attention to maintenance helps you move up and on to bigger projects and responsibility. Like all things, pursue a middle ground of philosophy. ie You can fiddle with code forever trying to make it "better". More extensible, more maintainable, more clear, more more more. Arguing over future cases (premature planning) is the most common sin. Planning for everything to be reused is not being efficient. Regardless, you have biases that inform what you think is "better" and how software will be used, which future you (and other developers) will note share.
- josephg 4y ago
  > Arguing over future cases (premature planning) is the most common sin.. There's definitely a scale between "unmaintainable mess" and "architecture astronomy" where both extremes are pathological. I've seen plenty of unmaintainable messes in my time - particularly from average teams who are lacking in good technical leadership. You see this sort of thing all the time in consulting, and in software teams at non-software companies. (Eg, in the airline industry). There's a reason why Martin Fowler talks a lot about software craftsmanship - because at places like Thoughtworks they could often use more of that sort of thinking. I've also seen plenty of overengineered messes too. Most smart college students (myself included) seem to need to go through this at some early point in our careers, where we really spread our wings and discover first hand why writing thousands of java classes is a terrible idea. (Or whatever the poison of the day is). If all your abstraction does is move your food (business logic / algorithms) around the plate, or -worse- hide it, then your abstraction is making the code worse. I have no idea which sin is more common. I think it really depends on what sort of engineers you spend time with. Google definitely suffers from the second kind of problem much more than the first - to the point where google (hilariously) often outsources making actual websites to external consulting companies, because their own software practices are too expensive to implement. Does your team need more long term thinking or more short term thinking? Its impossible to answer without reference to your actual team, your existing practices, and what you're trying to deliver. A weekend game jam should be scrappy, and the code for the space shuttle should be written carefully. Neither approach is objectively good or bad; there's just different tradeoffs appropriate for different kinds of project. The best senior programmers can switch style & philosophy based on whats needed for the task sitting right in front of them.