2010-02-10 21:29:44.054237+00 by Dan Lyke 5 comments
Elf Sternberg: What went wrong at ${Job Sept’09-Oct’09} points to Gwaredd Mountain: Game Development in a Post-Agile World which points to Microsoft's data showing that "test driven development" increases development from 15-35%, all three are worth reading on the hazards of side effects in your software development methodologies.
[ related topics: Humor Games Microsoft tolkien Software Engineering moron Heinlein ]
comments in ascending chronological order (reverse):
#Comment Re: made: 2010-02-10 22:43:30.349539+00 by: Shawn
[Disclaimer: I haven't read the article(s) yet]
> data showing that "test driven development" increases development from 15-35%
At the risk of sounding like an ass... Well, duh. Is there really anybody who didn't realize/acknowledge that? The argument is that the [claimed] benefits [can] outweigh the increased development, thus providing a net improvement.
[Okay, now that I've at least read Elf's quote of Gwaredd's post...]
> we cannot possible consider anything that adds an extra 35% effort to > produce artefacts the customer will never see as lean
Personally, it sounds to me like the problem is one of giving too much weight to customer demands. Yes, I agree the customer is an important part of the equation, but [our industry] often bends over backwards to keep the customer happy at the expense of quality, security, etc. Consumer expectations have gotten out of hand in [U.S.] society. People need to learn, and come to accept, that sometimes its in their best interest to let the experts do what they're being paid to do in the best way possible.
#Comment Re: made: 2010-02-11 02:32:11.802359+00 by: markd
A lot depends on the nature of the project as well. Basecamp could get away with "lean and mean", doing the customer-billing-after-launch thing because updating web apps is easy. Introduce a horrible bug? Roll it back. Or push a quick fix. If you're doing stuff like complex desktop software, then having more tests and more rigor is good. Release a version that corrupts the user's data, or worse wipes out stuff on their machine, that's pretty hard to roll back.
I think TDD is too over-the-top. Our jobs are to solve problems we haven't seen before (otherwise we're just re-implementing yet another accounting system). Kind of hard to test the unknown first. Once you've solved part of the problem, write the tests to reinforce that you know you've solved it, and move on.
My current project is a tricky piece of infrastructure for desktop apps, and we have a lot of tests with a lot of coverage. They've saved my butt more times than I can count. A web app for my friend where you upload a Garmin heart rate monitor file and it calculates Heart Zone Points, I probably wouldn't write tests.
#Comment Re: made: 2010-02-11 07:54:06.320362+00 by: ebradway
Shawn: I think that's Apple's current approach.
#Comment Re: made: 2010-02-11 15:09:40.531043+00 by: TheSHAD0W
Maybe we should make desktop software more like its cloud-based cousins. Journal peoples' data changes, so things can be rolled back and even regenerated in the case of a software goof.
#Comment Re: made: 2010-02-11 15:46:01.662278+00 by: markd
And if you don't have tests on the journal, and it hoses things? You also still have the distribution problem. Three million folks have the software, it hoses the data. Now there's all those folks who need the new version. That's expensive in terms of time, bandwidth, and support. And that's assuming they even update. Having N-dozen rapid-iteration versions out in the wild can become a support problem too.