Cesspool Methodology

A friend and colleague described a horrible project that he participated in. This project was bad, really bad.
I know a few people who were part of the team and all of the members that I respected did whatever it took to get away from that project as fast as they could. The project is also tragic, because it could have been really good, but it was ruined.
The mission of the project was to replace an existing set of applications with a single web application. Each application contacted a different system in the company. There were some old green screen applications and an early generation Java web application. It was all going to be replaced with a nice integrated ajaxed web application.
The sharp developers suggested that they just break pieces of what they know needs to be done off and develop them quickly with the understanding that it would be used by other parts of the program. I think they used a word, ag-eel-aye, must be Italian. I don't know what happened with agile exactly. It sounded like they were doing it for a while on the sly when someone found out and raised hell.
Instead of agile, the methodology that this project team's management chose to use is what my friend described, not as a waterfall, but a cesspool. He explained the differentiation, "a waterfall would imply that progress is being made."
The developers et. al. were set on a mission to document how the existing applications work. Every detail must be documented before anything else gets done. After the weeks of documenting the old applications, the developers were then tasked with documenting how the new application would work, everything must be documented, no development would begin on the new application until the documentation and design of the new application is finished. So throw another couple of weeks away.
Why is this a terrible idea? Well, documenting is to many developers a form of punishment. It's like the myth of Tantalus where you are in a position to look at what you want to do, but be unable to actually do it.
This method is doubly bad for developers. Not only do you need to look at what you want to do and do nothing about it, you also need to look at what was done before and do nothing about it. Couple all of this with the well known, if not documented, fact that documentation is a highly perishable good. It's wrong almost as soon as it's written, and unless there are technical writers, people who actually enjoy documenting things, it's probably not going to get corrected.
There's no payoff in sight for the developers. They're already sick of the project by the time they get to do what they enjoy.
I would urge anyone who finds themselves in a cesspool project to leave immediately.