Re^5: An interesting rebuttal of "agile"

[talexb]

in reply to Re^4: An interesting rebuttal of "agile"
in thread An interesting rebuttal of "agile"

I think it's pretty clear that your development environment and mine differ pretty widely -- which is why you can go from a development build to a release in a couple of hours, and I cannot.

At my previous job, I was the only web developer. I was also the only 24/7 support person, and the only internal support persion. I also got the opportunity to bounce ideas off the CTO, and have him bounce ideas off me. My test persion was actually working full-time on Production and I had to schedule a few hours for her to get time to test a build (development sometimes -- milestone and release always).

But I also strongly believe that it's important for software to released as a 'slightly used' version, rather than something fresh and hot from the repository and the QA department. That may be a result of the staffing available to me, but it makes more sense to me to bang around a release for a few days, and then say, "Well, no show-stoppers in the last few days -- let's release!"

[chromatic]

That may be a result of the staffing available to me, but it makes more sense to me to bang around a release for a few days, and then say, "Well, no show-stoppers in the last few days -- let's release!"

I've also worked in very small teams where we had no dedicated QA. Even then, I have a severe distrust of the kind of ad hoc testing you get from banging around a release for a few days to see if any of the bugs in the product somehow appear. If anyone finds a bug, I want to find it, understand it, fix it for good, and then ensure that it and bugs like it can never appear again. I don't think you get that without serious testing and root cause analysis, and I know you don't get that often (if ever) if QA is a separate entity from development.

[jplindstrom]

If anyone finds a bug, I want to find it, understand it, fix it for good, and then ensure that it and bugs like it can never appear again. I don't think you get that without serious testing and root cause analysis, and I know you don't get that often (if ever) if QA is a separate entity from development.

Of course it's good to have embedded testers. But I don't think it has much to do with whether bugs get fixed properly or not.

Whether that happens or not seems to me to be more a function of the mindset of the developer, whether he concentrates on fixing the symptom of the bug or fixing-the-hell-out-of-the-bug(tm) once it is found.

/J