Testando

The CRUD Methodology
Akiva Leffert Pomegranate Inc.

I know thy works, and thy labour, and thy patience... - Revelations 2:2 Recent years have seen the rise of a number of software engineering methodologies with a variety of silly names like Extreme Programming(XP)[2] and Scrum[7] grouped under the umbrella of agile development. These methodologies vary wildly in approach, but have several aspects and goals in common: A focus on rapidly developing working code, keeping requirements clear, and aggressive unit testing. However, these approaches are designed to produce software that works, at least that is their claim. Few have tackled programming processes for software that doesn’t work and isn’t meant to. In the remainder of this paper, we present Creating Rubbish Using Developers(CRUD)1 . A methodology for producing bad code. We first present and elucidate the principles of CRUD. We then present examples of the CRUD methodology in action. Finally, we talk about applying CRUD to your software process and how you can reap the benefits of CRUD.

1

Principles of CRUD

It is important for a software development methodology to have principles. Otherwise, the other methodologies would consider it a weak-kneed spineless jellyfish[5] hack of a process and will steal its lunch money, leaving it penniless and sad[4]. Also, lists of principles look good on Wikipedia[8] pages and glorified blog posts[6] promoting its merits. The principles of CRUD are simple: 1. Don’t think. 2. Don’t act. There are many ways to produce software that doesn’t work e.g. too few programmers, too many programmers, incompetent management, incompetent programmers, contracting to a sketchy guy on the street, bubonic plague, unclear requirements, extremely clear but impossible to implement requirements, demonic possession, dependence on outside code, bad tools, and getting involved in a land war in Asia. However, most of these methods are unreliable, programmers occasionally thrive despite bad