First, continuous deployment works fine for web projects, but it's not an option if you've got a packaged product that you have to ship at some point. Agile is not a panacea for these environments.
It's important to differentiate between the two kinds of software that you can write. This is post is dead-on for developing truly new software (new features, stuff that fundamentally hasn't existed before, etc). However, estimation (even the kind of project-manager-driven estimation that most engineers, myself included, generally hate) can work really well for software where you're doing basically the same thing you've already done in the past such that the risk of unknown unknowns is extremely low. I've seen it in practice, and when you have a checklist of stuff to do that you've already done with very minor changes in the past that can't be automated for whatever reason (e.g., support a new piece of hardware, except that the new piece of hardware is basically the same as the old piece of hardware with very minor well-documented changes), you can estimate with surprisingly good accuracy.
Yes, but a decent amount of software is doing things that are relatively unique to the time, place, and organization creating it.
For those sorts of projects, you might as well use this equation for time to completion: sum of(number of lines in the spec/request * d4)*3 = days to complete.
> continuous deployment works fine for web projects, but it's not an option if you've got a packaged product that you have to ship at some point. Agile is not a panacea for these environments.
I think that misses one of the key insights of continuous deployment. The biggest gain in CD is not about actually pushing code to production on every commit, but working as you actually do push to production on every commit.
This means that commits are small, contain tests, are delivered frequently and don't break the build. That workflow is a good idea, regardless of the final product or industry.
I practice CD (hell, I built a company to do CD), but if I ever had to go back to shipping desktop software or whatever, I'd still practice CD.
It's important to differentiate between the two kinds of software that you can write. This is post is dead-on for developing truly new software (new features, stuff that fundamentally hasn't existed before, etc). However, estimation (even the kind of project-manager-driven estimation that most engineers, myself included, generally hate) can work really well for software where you're doing basically the same thing you've already done in the past such that the risk of unknown unknowns is extremely low. I've seen it in practice, and when you have a checklist of stuff to do that you've already done with very minor changes in the past that can't be automated for whatever reason (e.g., support a new piece of hardware, except that the new piece of hardware is basically the same as the old piece of hardware with very minor well-documented changes), you can estimate with surprisingly good accuracy.