4 ms·

The thing that is very frustrating in the "There was never time to change decisions..." bit is that there often is time. If you are curious about what I mean,

The thing that is very frustrating in the "There was never time to change decisions..." bit is that there often is time. If you are curious about what I mean, I invite you to try a little experiment. For a few weeks (2-4 should be sufficient) tell people, "If you see something wrong with the design, refactor it as soon as you see it. If you need some extra time on your story to compensate for that work, just bring it up at standup and we will modify the sprint commitment". If your experience is like mine, you will find that the vast majority of people will not refactor the design at all. About 10% of the people will try to refactor something, and will end up trying to rewrite the entire app. They will do more damage than good and will probably give up half way through. If you are lucky, maybe 5% will actually refactor something and be successful. Because I have tried this many times, I've interviewed people and asked them why they do what they do. For the people who don't refactor, the reason they usually give is: "There is no time to refactor". Which is really odd because they have explicitly been given time. What I have come to realize, though, is that people do not want time; they want absolution of responsibility. If you ask them to make the judgement call, they do the math in their head (unconsciously) and determine that they will be rewarded more and criticised less if they do feature work without refactoring. This forces the decision up to the PM/PGM/BM/BA/Whatever, for whom refactoring has no direct benefit. The result is that refactoring is rarely done, and if it is done it is the result of a large political process. For the people who try to rewrite everything, training seems to be the overwhelming issue. They pull on a thread and the whole sweater comes apart. For some people in this category, though, giving them carte blanche to decide what to do means that they feel they can finally "do it right". Doing it right in this context means that they can replace all the code that they didn't personally write and therefore don't like. Since everyone on the team only writes a small portion of the code, it means that rewriting everybody else's portion is basically rewriting the app. Again, training seems to help because even if a person's goal is to replace everything, if they learn how to do it piece by piece they can be successful. Also if they do that, they will be required to have many coversations and may eventually learn how to work with others. Finally, you may get one or two people who naturally know how to refactor well. It is useful to find out who these people are and to encourage them. Unfortunately, this often enrages the "my way or the highway" people. The people who are good at refactoring, if encouraged, will naturally dominate the design of the application. Often these people are suppressed by political means because they are so effective at driving the design. In order to enable these people you will need to make some tough decisions on the business end of things.

tracker1 11y ago
As a developer I've had some very good and very bad experiences... usually centered around two issues.. 1. I am not a morning person and am consistently late, I get work done, but not at 8/9am on the dot. And, 2. because I will take the time to understand what I am working on... this usually results in some refactoring and generally less code in the end. I once saved enough code in size to include lodash, and eventemitter into the client side of a project, by refactoring out a piece using those two libraries. I was of course chastised because it took longer than expected. I left when the writing on the wall was I would be fired anyway... That was over a year ago, and my understanding is the project I was working on with a 3 month delivery time still isn't done because no effort was made to resolve technical debt and they kept throwing more people/teams at it.
- ThrustVectoring 11y ago
  From the outside, it's rather hard to tell the difference between someone getting problems that are "inherently simple" and someone spending time finding simpler solutions to problems.
  - BWStearns 11y ago
    That's actually an interesting question. Aside from problems that are easily observable as difficult because lots of smart people have tried and failed, how can one objectively know whether it was difficult or easy? Even within "just a web app" one can run into some gnarly issues or odd old code that renders otherwise simple tasks difficult, but since it's only one person working on it you can't really test whether or not it's actually difficult. This might impact both the dev/manager disconnect as well as imposter syndrome.
PopeOfNope 11y ago
For the people who don't refactor, the reason they usually give is: "There is no time to refactor". My #1 reason to avoid refactoring code is because that code has been there, is battle tested and hasn't had a bug filed against it in months. That is not my first instinct, either. There are lots of things I see that I had written months ago that I badly want to rewrite every time I see it. I have to restrain myself because it's not just the time spent refactoring. It's writing tests (if you're into that sort of thing). It's getting QA to hammer on it some more. It's fixing all the little bugs that you thought you had fixed that you re-broke. It's all the little bugs you've never seen before because this is a new design and you're not perfect. Most of the time, it's not worth the refactor, even if it does slow down adding future features to that particular area. There are, of course, two exceptions: 1) if you're constantly playing bug whack-a-mole on a particular section and 2) if a section of the code you're working on is constantly changing. I grasp every opportunity to hold a meeting, stand on the nearest chair, strike a dramatic pose and shout "We are rewriting the loading system... FROM SCRATCH!" My project manager then tells me to get down and lay off the coffee, but that's ok, I've had my moment.

tracker1 11y ago

As a developer I've had some very good and very bad experiences... usually centered around two issues.. 1. I am not a morning person and am consistently late, I get work done, but not at 8/9am on the dot. And, 2. because I will take the time to understand what I am working on... this usually results in some refactoring and generally less code in the end. I once saved enough code in size to include lodash, and eventemitter into the client side of a project, by refactoring out a piece using those two libraries. I was of course chastised because it took longer than expected. I left when the writing on the wall was I would be fired anyway... That was over a year ago, and my understanding is the project I was working on with a 3 month delivery time still isn't done because no effort was made to resolve technical debt and they kept throwing more people/teams at it.

ThrustVectoring 11y ago
From the outside, it's rather hard to tell the difference between someone getting problems that are "inherently simple" and someone spending time finding simpler solutions to problems.
- BWStearns 11y ago
  That's actually an interesting question. Aside from problems that are easily observable as difficult because lots of smart people have tried and failed, how can one objectively know whether it was difficult or easy? Even within "just a web app" one can run into some gnarly issues or odd old code that renders otherwise simple tasks difficult, but since it's only one person working on it you can't really test whether or not it's actually difficult. This might impact both the dev/manager disconnect as well as imposter syndrome.

PopeOfNope 11y ago

For the people who don't refactor, the reason they usually give is: "There is no time to refactor". My #1 reason to avoid refactoring code is because that code has been there, is battle tested and hasn't had a bug filed against it in months. That is not my first instinct, either. There are lots of things I see that I had written months ago that I badly want to rewrite every time I see it. I have to restrain myself because it's not just the time spent refactoring. It's writing tests (if you're into that sort of thing). It's getting QA to hammer on it some more. It's fixing all the little bugs that you thought you had fixed that you re-broke. It's all the little bugs you've never seen before because this is a new design and you're not perfect. Most of the time, it's not worth the refactor, even if it does slow down adding future features to that particular area. There are, of course, two exceptions: 1) if you're constantly playing bug whack-a-mole on a particular section and 2) if a section of the code you're working on is constantly changing. I grasp every opportunity to hold a meeting, stand on the nearest chair, strike a dramatic pose and shout "We are rewriting the loading system... FROM SCRATCH!" My project manager then tells me to get down and lay off the coffee, but that's ok, I've had my moment.