
Refactoring to a Happier Development Team - GarethX
http://blog.fogcreek.com/refactoring-to-a-happier-development-team-interview-with-coraline-ada-ehmke/
======
crdoconnor
>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
>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
If you test at a high enough level you shouldn't have to throw the tests away
while refactoring.

~~~
Ace17
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
Why should those characterizing tests be throwable if you don't want to change
its behavior?

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

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

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

