I like to call this cowboy development, and it works well for some of us. I'm not sure it's suited to all people or environments. I think most coders have developed an application this way and it worked well because they were ecited about it and there were no porcesses to slow them down.
If you're working on your own thing, or you have a client that trusts you, it can blow away other development methodologies. I hear about TDD and BDD, agile this, etc. all the time, but I bet most coders who build something on their own don't actually start with tests etc. I just think that those who do are very vocal about it.
One big issue though is usually documentation. Once you're done, you get the huge sense of accomplishment and it can be a drag to go back and add massive amounts of documentation to what you've just done (not comments, I mean a developer guide for the next guy).
I used to call this cowboy development, but I think the term is unfair and draws an inaccurate parallel between this and a bunch of mediocre programmers hacking away without structure.
I made a point of not calling it agile either, because agile is actually very structured, not at all chaotic like this mode of development.
An important distinction with cowboy development is that you can do cowboy development with pretty much any programmers, but most programmers are not capable of this mode of development. It requires a very open and sharp mind (ability to discover and absorb new technologies at a very rapid pace and to embrace evolving requirements without always bitching about how requirements aren't stable).
Elite Cowboy Development then? I wasn't really trying to make a distinction about the coders capabilities. To be honest, I think it has more to do with creativity and drive than it does with mad maths or lambda the ultimate forum contributions.
Regardless I don't personally associate negative connotations with this method. I'm sure in some situations it can be disastrous, but nothings perfect and I guarantee there have been plenty of agile disasters as well.
Call it Pam - Project adapted methodology. The amount of rigor the development process needs depends on the project and the developers. With experienced developers, who are good at communication and negotiation (i.e. no big ego problems) working in a problem domain which they understand (i.e. no big unknowns waiting to bite) this is probably the quickest way to get a great product.
If you're working on your own thing, or you have a client that trusts you, it can blow away other development methodologies. I hear about TDD and BDD, agile this, etc. all the time, but I bet most coders who build something on their own don't actually start with tests etc. I just think that those who do are very vocal about it.
One big issue though is usually documentation. Once you're done, you get the huge sense of accomplishment and it can be a drag to go back and add massive amounts of documentation to what you've just done (not comments, I mean a developer guide for the next guy).