3 ms·

Refactoring is a necessary outcome of poor design choices. It is obvious that in a perfect world with perfectly designed software, you would never refactor righ

by mempko 10y ago

Refactoring is a necessary outcome of poor design choices. It is obvious that in a perfect world with perfectly designed software, you would never refactor right? While I applaud your continued effort at perfection, the goal should be less refactoring not more. Not less refactoring because we don't care about quality, but less refactoring because we get more right from the start.

tboyd47 10y ago
^ This. Instead of responding to productivity slowdowns by pointing the finger at clients for rushing us in the beginning, could we figure out how to respond better to rushing while it's going on? It really makes you think about our industry.
Ericson2314 10y ago
I agree in principle, but here's two big (and heavily opinionated) real-world phenomena that push back: 1. As a die-hard function programmer believe most everything out there is designed poorly---not because everybody incompetent but because anything working with poorly designed languages and libraries must itself necessary be less well designed. Bad abstractions breed other bad abstractions! To write near-ideal software usual an excise of ripping up the foundations---so a lot of refactoring. 2. We learn good design best by refactoring. When righting new code, functionality and elegance are competing goals, but when refactoring elegance can be tackled in isolation. Furthermore, refactoring is an opportunity to prove (to oneself and others) that given abstractions indeed make code better. Finally, it's hard to distill good design to principles beyond "don't repeat yourself" and "make bad things impossible", but refactoring offers an opportunity to try things and see what works.
- biocomputation 10y ago
  It's like we're the same person. I've found it next to impossible to get it through ( some ) people's thick heads that refactoring is not a sign that something was done wrong the first time around. >> We learn good design best by refactoring. Exactly. This is often when the true value of a design pattern becomes crystal clear in an applied ( rather than theoretical ) sense.
  - Ericson2314 10y ago
    You mentioned C++, but do you do statically typed functional programming too? Then we are the same person :).
    - biocomputation 10y ago
      I haven't done any statically typed functional programming. I'm interested in some parts of functional programming, mostly as they related to replacing raw logic with functions.
      - Ericson2314 10y ago
        Well C++ definitely rewards care and effort in a similar way. Haskell and Rust (to get specific) are good for me cause they allow one to write much more air-tight abstractions, raising the upper limit on what my constant refactoring can yield. No more of that "all abstractions leak" bullshit!
brandonbloom 10y ago
> Not less refactoring because we don't care about quality, but less refactoring because we get more right from the start. Requirements always change and information is never perfect. You can't always get everything right from the start because you might not even know what you're trying to get right. If you get malleability right from the start, you'd expect _more_ refactoring, since it's easier to do when you inevitably want to. If you're going to spend effort on trying to get things right from the start, that's where you should focus: Minimize things that are slow change, maximize things that make change less painful. Concretely, this means spend less time code reviewing local variable names and curly brace style; spend more time reviewing public APIs, data format definitions, promised external semantics, etc. with an eye for versioning, deprecating, evolving, etc.
cle 10y ago
Disagree, the goal is to maximize net value. Getting more right from the start largely depends on your specific project and how well you can predict the future. In highly unpredictable environments, you're better off not trying to predict the future, because you'll likely be wrong, which will cost you more than if you didn't try in the first place.

by mempko 10y ago

tboyd47 10y ago

^ This. Instead of responding to productivity slowdowns by pointing the finger at clients for rushing us in the beginning, could we figure out how to respond better to rushing while it's going on? It really makes you think about our industry.

Ericson2314 10y ago

I agree in principle, but here's two big (and heavily opinionated) real-world phenomena that push back: 1. As a die-hard function programmer believe most everything out there is designed poorly---not because everybody incompetent but because anything working with poorly designed languages and libraries must itself necessary be less well designed. Bad abstractions breed other bad abstractions! To write near-ideal software usual an excise of ripping up the foundations---so a lot of refactoring. 2. We learn good design best by refactoring. When righting new code, functionality and elegance are competing goals, but when refactoring elegance can be tackled in isolation. Furthermore, refactoring is an opportunity to prove (to oneself and others) that given abstractions indeed make code better. Finally, it's hard to distill good design to principles beyond "don't repeat yourself" and "make bad things impossible", but refactoring offers an opportunity to try things and see what works.

biocomputation 10y ago
It's like we're the same person. I've found it next to impossible to get it through ( some ) people's thick heads that refactoring is not a sign that something was done wrong the first time around. >> We learn good design best by refactoring. Exactly. This is often when the true value of a design pattern becomes crystal clear in an applied ( rather than theoretical ) sense.
- Ericson2314 10y ago
  You mentioned C++, but do you do statically typed functional programming too? Then we are the same person :).
  - biocomputation 10y ago
    I haven't done any statically typed functional programming. I'm interested in some parts of functional programming, mostly as they related to replacing raw logic with functions.
    - Ericson2314 10y ago
      Well C++ definitely rewards care and effort in a similar way. Haskell and Rust (to get specific) are good for me cause they allow one to write much more air-tight abstractions, raising the upper limit on what my constant refactoring can yield. No more of that "all abstractions leak" bullshit!

brandonbloom 10y ago

> Not less refactoring because we don't care about quality, but less refactoring because we get more right from the start. Requirements always change and information is never perfect. You can't always get everything right from the start because you might not even know what you're trying to get right. If you get malleability right from the start, you'd expect _more_ refactoring, since it's easier to do when you inevitably want to. If you're going to spend effort on trying to get things right from the start, that's where you should focus: Minimize things that are slow change, maximize things that make change less painful. Concretely, this means spend less time code reviewing local variable names and curly brace style; spend more time reviewing public APIs, data format definitions, promised external semantics, etc. with an eye for versioning, deprecating, evolving, etc.

cle 10y ago

Disagree, the goal is to maximize net value. Getting more right from the start largely depends on your specific project and how well you can predict the future. In highly unpredictable environments, you're better off not trying to predict the future, because you'll likely be wrong, which will cost you more than if you didn't try in the first place.