What most people used to do on small internal IS applications and commercial products. Essentially, there is no QA, no requirements, no plan, and definitely no design. Furthermore, there is no unit testing (or testing of any kind) and the only verfication is done with a debugger ''after'' the code is written.

RapidDevelopment calls this CodeAndFix.

Then again, I'm sure none of ''you'' every did this sort of thing....

''Isn't this just the CowboyCoding?''

For some reason I always think of a Cowboy Coder as an individual rather than an entire team. I suppose I shouldn't be that narrow.

''CC implies you'd wrather code alone for some strange reason. --PCP''

----

I wouldn't be so hard on this kind of development.  It is a defensive technique when deadlines are impractical, and design efforts are disconnected from reality.  To say there is no design is probably not accurate.  There is most likely a constantly evolving design, which for reasons of efficiency and conflict avoidance is kept secret from non-programmers.  Remember the scene from LifeOfBrian where the illiterate and mute slaves converse in a highly-educated fashion when their overseers are gone?  Judge the quality of the design by the result, not by the weight of the external documentation or the degree of management comfort.

----
I think it is just the opposite. A of use on CodeAndFix projects used to auto-generate case or data-flow documentation ''just'' to make management feel good -- pretending it was done before the fact rather than after!! We programmers were flying by the seat of our pants and would do anything to keep from having to design things up front. As I evolved, I began to care more about process and design myself, not just to make my managers feel more comfortable. There seems to be a funny misconception that "design == documentation". Where did anyone mention "external documentation"?