Michael D. Hill On Too Much

Posted on 07.11.2010 by Antti Holvikari

Old post by Michael D. Hill on the XP mailing list. These are also some of the reasons I like XP. It keeps things real, while at the same time embracing good engineering practices. Read the whole thing.

  1. Unbelievably complicated unit testing frameworks: You don’t need them. You need the ability to write a test function, add it to a list of test functions, and call them. How long will it take you to write that code? Four hours? Six? Write it. Over time you may see other things that will be handy, but you don’t need them now.

  2. Corner cases you’ve invented where the XP method seems to have contradicted itself: You don’t need them. If you really encounter them in the field, which for the most part I seriously doubt you ever will, here’s how you solve them. 1) Pick one interpretation or the other. 2) Implement it. 3) Try it. 4) If you don’t like it, change it until you do. 5) If you can’t change it enough, pick the other interpretation.

  3. Unbelievably-difficult-to-unit-test classes you’ve created: You don’t need them. If it can’t be unit-tested, it can’t be a stable central part of your code, so throw it away. Divide one staggeringly complex object into thirty dead simple ones. Unit test them.

  4. Umpty-nine-levels of inheritance and abstraction with private inner reverse-schreck semiotic slipsoid sub-class interactivity devices that make your design impossible to even describe, let alone debug: You don’t need them. I am truly staggered to hear how many folks are using the arcana of their programming environments rather than the mainstream.

  5. The generic solution to all problems having to do with a generalized and abstract class representing XXXXX’s: You don’t need it. You need a class representing XXXXX’s AS SEEN BY YOUR CUSTOMER’S USER STORIES. Code one. Forget about dividing the world up into philosophically correct hierarchies. Divide the problem into pragmatically correct ones.

  6. Unit tests that are designed to prove that your object will survive a thermonuclear blast: You don’t need them. Unit tests should be renamed object tests, an argument I’ll take up later. Write a unit test to test ONE object, not all that objects that one talks to. If you cannot find a way to do it, your object is almost certainly too complicated. Simplify it, and try again.

  7. Unit tests that are really functional tests: You don’t need them. The functional tests prove that everything works together to satisfy the customer’s stories. The unit tests do not exist to prove that your program is correct. They exist to make your work faster and easier. Pretend your object is floating in a petri dish, not in a live cell. Test it without testing its neighbors. If you can’t, re-write until you can.

  8. Paint-scraper programs that capture and test screen output for form-based apps: You don’t need them. De-couple all program functionality from UI functionality. Unit-test it. Write generic client-controls that use generic data-servers. Unit-test them. Derive concrete data-servers connected to your model. Unit-test them. Build forms by connecting clients to servers. Unit-test them for tab-order and screen-layout. Get your functionals to 100%. Ship. Wait for stock options to mature.

blog comments powered by Disqus