Unlocking the Awesome Power of Refactoring with J.B. Rainsberger
Evolutionary design, and in particular refactoring, has the power to drastically improve the moment-to-moment work of programmers. Employers are interested in delivering work sooner, over-investing less often in up-front design, wasting less time yelling about design decisions in meetings, and hearing fewer rationalizations from programmers about why it takes so long to get anything done. Programmers often care about those things, too, but I care even more about helping them do their work with less stress: more confidence about where the design is heading, that they can adapt the design to changes in requirements, that they can experiment freely without committing "forever" to every design decision, and recovering more easily when one of their colleagues insists on pushing a bad idea only to realize later what a bad idea it was. Reducing the cost of changing our minds frees us up _and_ generates better results. Everyone wins.
Many programmers get stuck when they try to learn evolutionary design, particularly the refactoring part of it. It never seems to get easier, it never seems to go faster, and so it always seems safer to rip things apart and write them again. If you or someone you know feels stuck like this, then let's talk about why that happens and what to do about it.