5 ms·

Refactoring to a Happier Development Team

66 points by GarethX 11y ago

Rygu 11y ago
> In the end, if none of that works, just cheat. Just lie and pad your estimates, so you automatically build in some time for reducing technical debt with all of your estimates, which unfortunately I’ve had to use more often than I would like to have used. It is a valuable tactic to keep in your toolbox. Interesting opinion. However I cannot agree with this part that tries to justify having a personal agenda and putting it above the company's mission. Unless you're fighting an executive level fight (probably not a good idea then either) there's no good reason to exaggerate stories about technical debt unless it forms an immediate impediment. You might end up being the one who killed your company.
- zo1 11y ago
  It's not a personal agenda. It's a professional quality line, that you as a professional need to maintain. On a typical day, you don't vary the quality of output to match the deadline. The deadline should adjust to accomodate the amount of time it'll take you to complete the feature at the quality level you deliver.
  - e28eta 11y ago
    Agreed. She mentions "code that's good enough", and I think that's the problem I encounter at work. Take the extra time to write bug free and maintainable code, which means the task might take longer if refactoring is required. There should be no problem refactoring code in pursuit of building a feature or fixing a bug. If you're refactoring unrelated code, that's where it gets a little dicier.
- gorena 11y ago
  > You might end up being the one who killed your company. If an extra day to clean up your code is an issue, your company is already dead. What if you have to push it back a day because you get sick?
  - matwood 11y ago
    I agree, but the problem is that it is never 'just a day.' Developer comes and needs a couple hours to clean up some code. Cool, the a couple hours turns into a day, then a week, then no new features are being shipped. It is very easy to get into a constant refactoring perfectionist state to the point where nothing ships. It is so common in fact that we have memes about 'real engineers ship'.
- grayclhn 11y ago
  I would rephrase that as "putting the company's mission above specific instructions that are detrimental to that mission." Intent and judgment matters a lot here: if someone has good judgment and is sincerely trying to make the product or company better, he or she should have some leeway. Selfish losers shouldn't, but I don't think that part of the article was directed at them.
- s73v3r 11y ago
  Who says you're putting it above the company's mission? Paying down the technical debt makes it easier to roll out changes in the future, which would make the company more competitive.
GarethX 11y ago
Anyone else have any experience of Developer Happiness teams? This was my first time hearing about one and I wonder how well it works in practice and how other non-dev teams react to it.
- egusa 11y ago
  i hadn't heard of this before, but i think it's a great idea and am surprised i don't see it more often. "We were charged with increasing the happiness and productivity of the engineering team."
  - crpatino 11y ago
    Fogcreek is a deviant, if progressive, company. You will find the norm is to pay lip service to the "happiness and productivity of the engineering team" but when push comes to shove, it is Death-march time all over again.
    - gjm11 11y ago
      The person with the "Developer Happiness Team" is not at Fog Creek. Fog Creek are conducting interviews with various people at other companies. Any deficiencies Fog Creek's own development processes may have are irrelevant to this interview, so far as I can see.
- venantius 11y ago
  We have one at Airbnb, and it's great. They regularly put out tools for internal use that help the whole company move faster. Everybody still ends up doing some local development environment optimization, of course, but having a small team that's dedicated to making things easier for the whole company is really valuable.
- zem 11y ago
  this post about the "engineering effectiveness" team at twitter is relevant: http://www.gigamonkeys.com/flowers/ http://www.gigamonkeys.com/flowers/
crdoconnor 11y ago
>The most important tests, though, for refactoring are tests that you throw away. We’re hesitant. We love deleting code, but we hate deleting tests, because it gives us this feeling of insecurity. The sort of test that you do during refactoring doesn’t lend itself well to maintaining code over time. You’re going to be a lot more granular in your tests. You’re going to be testing things that are outside of the purview of normal integration or unit tests, and it’s important that you feel comfortable throwing those away when you’re done with a refactoring effort. If you're throwing away a lot of your tests, that's generally a sign that your tests and your code are too tightly coupled.
- snappy173 11y ago
  >that's generally a sign that your tests and your code are too tightly coupled. I think that's the point. These are tests written specifically to help with the transition from the old to the new code. They are pretty tightly coupled to both versions in that sense. Once the old code is gone, they are really only testing the new code, so you throw them away.
  - crdoconnor 11y ago
    If you test at a high enough level you shouldn't have to throw the tests away while refactoring.
    - Ace17 11y ago
      You need throwable characterization tests when you don't know what the legacy code is supposed to do, but don't want to change its behaviour.
      - crdoconnor 11y ago
        Why should those characterizing tests be throwable if you don't want to change its behavior?
        11y ago

66 points by GarethX 11y ago

Rygu 11y ago

> In the end, if none of that works, just cheat. Just lie and pad your estimates, so you automatically build in some time for reducing technical debt with all of your estimates, which unfortunately I’ve had to use more often than I would like to have used. It is a valuable tactic to keep in your toolbox. Interesting opinion. However I cannot agree with this part that tries to justify having a personal agenda and putting it above the company's mission. Unless you're fighting an executive level fight (probably not a good idea then either) there's no good reason to exaggerate stories about technical debt unless it forms an immediate impediment. You might end up being the one who killed your company.

zo1 11y ago
It's not a personal agenda. It's a professional quality line, that you as a professional need to maintain. On a typical day, you don't vary the quality of output to match the deadline. The deadline should adjust to accomodate the amount of time it'll take you to complete the feature at the quality level you deliver.
- e28eta 11y ago
  Agreed. She mentions "code that's good enough", and I think that's the problem I encounter at work. Take the extra time to write bug free and maintainable code, which means the task might take longer if refactoring is required. There should be no problem refactoring code in pursuit of building a feature or fixing a bug. If you're refactoring unrelated code, that's where it gets a little dicier.
gorena 11y ago
> You might end up being the one who killed your company. If an extra day to clean up your code is an issue, your company is already dead. What if you have to push it back a day because you get sick?
- matwood 11y ago
  I agree, but the problem is that it is never 'just a day.' Developer comes and needs a couple hours to clean up some code. Cool, the a couple hours turns into a day, then a week, then no new features are being shipped. It is very easy to get into a constant refactoring perfectionist state to the point where nothing ships. It is so common in fact that we have memes about 'real engineers ship'.
grayclhn 11y ago
I would rephrase that as "putting the company's mission above specific instructions that are detrimental to that mission." Intent and judgment matters a lot here: if someone has good judgment and is sincerely trying to make the product or company better, he or she should have some leeway. Selfish losers shouldn't, but I don't think that part of the article was directed at them.
s73v3r 11y ago
Who says you're putting it above the company's mission? Paying down the technical debt makes it easier to roll out changes in the future, which would make the company more competitive.

GarethX 11y ago

Anyone else have any experience of Developer Happiness teams? This was my first time hearing about one and I wonder how well it works in practice and how other non-dev teams react to it.

egusa 11y ago
i hadn't heard of this before, but i think it's a great idea and am surprised i don't see it more often. "We were charged with increasing the happiness and productivity of the engineering team."
- crpatino 11y ago
  Fogcreek is a deviant, if progressive, company. You will find the norm is to pay lip service to the "happiness and productivity of the engineering team" but when push comes to shove, it is Death-march time all over again.
  - gjm11 11y ago
    The person with the "Developer Happiness Team" is not at Fog Creek. Fog Creek are conducting interviews with various people at other companies. Any deficiencies Fog Creek's own development processes may have are irrelevant to this interview, so far as I can see.
venantius 11y ago
We have one at Airbnb, and it's great. They regularly put out tools for internal use that help the whole company move faster. Everybody still ends up doing some local development environment optimization, of course, but having a small team that's dedicated to making things easier for the whole company is really valuable.
zem 11y ago
this post about the "engineering effectiveness" team at twitter is relevant: http://www.gigamonkeys.com/flowers/ http://www.gigamonkeys.com/flowers/

crdoconnor 11y ago

>The most important tests, though, for refactoring are tests that you throw away. We’re hesitant. We love deleting code, but we hate deleting tests, because it gives us this feeling of insecurity. The sort of test that you do during refactoring doesn’t lend itself well to maintaining code over time. You’re going to be a lot more granular in your tests. You’re going to be testing things that are outside of the purview of normal integration or unit tests, and it’s important that you feel comfortable throwing those away when you’re done with a refactoring effort. If you're throwing away a lot of your tests, that's generally a sign that your tests and your code are too tightly coupled.

snappy173 11y ago
>that's generally a sign that your tests and your code are too tightly coupled. I think that's the point. These are tests written specifically to help with the transition from the old to the new code. They are pretty tightly coupled to both versions in that sense. Once the old code is gone, they are really only testing the new code, so you throw them away.
- crdoconnor 11y ago
  If you test at a high enough level you shouldn't have to throw the tests away while refactoring.
  - Ace17 11y ago
    You need throwable characterization tests when you don't know what the legacy code is supposed to do, but don't want to change its behaviour.
    - crdoconnor 11y ago
      Why should those characterizing tests be throwable if you don't want to change its behavior?
      - 11y ago