Re: An interesting rebuttal of "agile"

in reply to An interesting rebuttal of "agile"

Having so much confidence in the testing and reliability and polish of your software that you can make a release from the trunk of your SCM every day is a problem?

If you have to release every day to fix bugs in the previous day's release, there's a problem... but the ability to release working software every day is not the root cause there.

Comment on Re: An interesting rebuttal of "agile"

Replies are listed 'Best First'.
Re^2: An interesting rebuttal of "agile" by Erez (Priest) on Mar 17, 2008 at 07:29 UTC
a release from the trunk of your SCM every day is a problem? My thoughts exactly, nightly builds is a known, respected, and in some cases even recommended process. Supplying the testers with a daily build is sometimes the best method of making sure the software actually works and that features are implemented correctly, bugs are actually fixed and nothing is broken in the process. I find Agile, as well as any other development methodology, to be like the usual adage about Best Practices, that is, use the parts that fits, discard the parts that don't, and, above all, remember that it is a suggestion rather than a rule, and means rather than a goal. It's a simple criteria one can apply to every Holy War, and the confusion of goal and means is what causes those Holy Wars. Software speaks in tongues of man. Stop saying 'script'. Stop saying 'line-noise'. We have nothing to lose but our metaphors.	[reply]

Replies are listed 'Best First'.

Re^2: An interesting rebuttal of "agile"
by Erez (Priest) on Mar 17, 2008 at 07:29 UTC

a release from the trunk of your SCM every day is a problem?

My thoughts exactly, nightly builds is a known, respected, and in some cases even recommended process. Supplying the testers with a daily build is sometimes the best method of making sure the software actually works and that features are implemented correctly, bugs are actually fixed and nothing is broken in the process.

I find Agile, as well as any other development methodology, to be like the usual adage about Best Practices, that is, use the parts that fits, discard the parts that don't, and, above all, remember that it is a suggestion rather than a rule, and means rather than a goal.

It's a simple criteria one can apply to every Holy War, and the confusion of goal and means is what causes those Holy Wars.

Software speaks in tongues of man.
Stop saying 'script'. Stop saying 'line-noise'.
We have nothing to lose but our metaphors.

[reply]

In Section Meditations