Refactoring to a Happier Development Team | Hacker News Reader

Refactoring to a Happier Development Team

blog.fogcreek.com

66 pointsGarethX19 comments

>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.

>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.

If you test at a high enough level you shouldn't have to throw the tests away while refactoring.

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.

Why should those characterizing tests be throwable if you don't want to change its behavior?

Because you may want or need to change aspects of the behavior, but not while refactoring.

> 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.

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.

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.

> 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?

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'.

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.

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.

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.

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."

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.

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.

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.

this post about the "engineering effectiveness" team at twitter is relevant: http://www.gigamonkeys.com/flowers/

Reply on news.ycombinator.com