Slashdot Mirror
Retrofitting XP-style Testing onto a Large Project?
Mr Pleonastic submits this query for your consideration: "I work for a small startup (ok, me and another guy comprise the entire development team) that has somehow managed to survive the bust, attract a number of customers, and build up about 300K lines of functionality. Up to now we've made it by being smart and conscientious hackers, but I'm increasingly embarrassed by our shortcomings in testing. I like the XP approach to making enduring, automated test suites, but most of what I read about XP focuses on obvious stuff and changing your programmer culture at the outset. Does anyone have experience with, or advice for, retrofitting it onto a fairly mature project? What do your test suites look like, anyway? The bugs I fear most are of the 'If the user does X and then Y, the result blows away our assumptions' variety, not the 'Oops! My function returned the wrong value' variety (which happens of course). How do you write good test code for the former, without spending even longer debugging the test code? Is XP just for small, new projects?"
Just make it open source. Then you can release whatever you want. If anyone has any problems with it then you can either blame them for breaking it or blame the open source community for not seeing the problem and fixing it right away. Just look at Mozilla.
However, this might make it hard to make money. But if you're into computers for money, then you should be working for the evil giant microsoft.
And just to be sure this message has appeal to be read, FUD FUD FUD. Open source, KDE, Gnome, FUD, FUD, FUD. Microsoft is the devil. There, that should do it.