The MUD process is a mature, widely-utilized software development process. It can be found in thousands of teams around the globe. Its primary aims are to allow developers to work simultaneously on a wide variety of projects without all the willy-nilly management cruft associated with other so-called “agile” processes.
MUD is characterized by several important features:
- Total absence of friction-heavy “code management” strategies. This includes the use of tools like source control as well as formal project plans and development standards. It takes a great deal of courage to go without these crutches, but the eventual outcome is that a team can write code as fast as their hearts desire.
- Total absence of politically-fraught “testing” strategies. Teams are encouraged to formulate their own validation processes. Without the normal multiple-back-and-forth cycle of testing, release cycles can be radically shortened. This is another point that requires lion-like courage, as teams could theoretically be shipping software with bugs if they don’t do full, formal testing.
- Speaking of which, total absence of any kind of “code validation” technique. Individual programmers are assumed to know what the hell they’re doing because sure as shit nobody else does, and good luck if they get hit by a bus. Coders should ideally be provided with Iron Man suits just in case they get hit by a bus or, more likely, have a heart attack.
- In fact, to hell with it. Just chain them to their desk until the customer says they can leave, which will be never. I would like to point out that this is still better than working at Electronic Arts, so be grateful, ya punk.
The MUD process produces functional code on a surprisingly regular basis. It gives people the freedom to stay at their desk rather than wasting their time trying to be something they’re not. To quote the MUD manifesto, written by Some Software Development Manager Guy:
”Uuuuum, we need that by Monday. Do whatever you have to do.”