3 ms·

I know the basic principles of extreme programming. But I ignored it (like most hotheaded fresh young devs are wont to do) till I rediscovered it some time earl

by nstart 12y ago

I know the basic principles of extreme programming. But I ignored it (like most hotheaded fresh young devs are wont to do) till I rediscovered it some time earlier this year. Do you have a go to book that discusses these practices? Already have a couple in my reference stack, just asking because you seem to have grasped the practice so well.

wpietri 12y ago
For programmers looking to learn about XP, the book that I most recommend is the first edition of Extreme Programming Explained by Kent Beck, the white one. (The second edition, the green one, was rewritten for a broader audience; also interesting, but I don't think it speaks as well to programmers.) But the book is ancient at this point, so I'd treat it more as a point of historical interest. We've learned a lot and our technology has changed greatly, so it's not something I'd recommend implementing as written. Another easy place to start is here: http://www.extremeprogramming.org/introduction.html http://www.extremeprogramming.org/introduction.html It's also out of date in some ways. For example, it talks about using a shared integration computer, but Git + AWS + Continuous Deployment have made that kinda ridiculous. But what I think of it as the core of it is still quite solid. In particular, the notion of thinking of a project not as a waterfall but as a series of self-correcting feedback loops has been immensely helpful to me. What XP gets really right versus, say, Scrum, is focusing on the minute-to-minute developer experience as a driver of quality and economy. Test-driven development, pair programming, sustainable pace, collective code ownership: when pursued vigorously, these have made a huge difference for me both in terms of project outcome and personal experience. My general tip for process change is for people to pick their biggest problem and then start solving it in a way that shortens feedback loops. So if somebody's getting lots of bugs in QA, then I'd encourage them to automate their tests so that developers get bug reports sooner. Or here, if the problem is long periods without knowing what's going on, it's breaking the work down into little chunks and delivering the next most valuable thing every few days. Humans are really good at optimizing short-feedback systems; we do a lot of it automatically. Feel free to write me if you have particular questions; people were very generous in getting me started. I'm glad to pay it forward.

by nstart 12y ago

wpietri 12y ago

For programmers looking to learn about XP, the book that I most recommend is the first edition of Extreme Programming Explained by Kent Beck, the white one. (The second edition, the green one, was rewritten for a broader audience; also interesting, but I don't think it speaks as well to programmers.) But the book is ancient at this point, so I'd treat it more as a point of historical interest. We've learned a lot and our technology has changed greatly, so it's not something I'd recommend implementing as written. Another easy place to start is here: http://www.extremeprogramming.org/introduction.html http://www.extremeprogramming.org/introduction.html It's also out of date in some ways. For example, it talks about using a shared integration computer, but Git + AWS + Continuous Deployment have made that kinda ridiculous. But what I think of it as the core of it is still quite solid. In particular, the notion of thinking of a project not as a waterfall but as a series of self-correcting feedback loops has been immensely helpful to me. What XP gets really right versus, say, Scrum, is focusing on the minute-to-minute developer experience as a driver of quality and economy. Test-driven development, pair programming, sustainable pace, collective code ownership: when pursued vigorously, these have made a huge difference for me both in terms of project outcome and personal experience. My general tip for process change is for people to pick their biggest problem and then start solving it in a way that shortens feedback loops. So if somebody's getting lots of bugs in QA, then I'd encourage them to automate their tests so that developers get bug reports sooner. Or here, if the problem is long periods without knowing what's going on, it's breaking the work down into little chunks and delivering the next most valuable thing every few days. Humans are really good at optimizing short-feedback systems; we do a lot of it automatically. Feel free to write me if you have particular questions; people were very generous in getting me started. I'm glad to pay it forward.