The YDD manifesto

There’s a new methodology that will completely change how you program: YDD. Take a break from the straight and narrow code and open your mind to the world of alternative IT methodologies.

Imagine our delight when the manifesto of a ground-breaking new methodology made its way into our inboxes. YDD prophet Todor Grudev has carved out in stone (on GitHub) the 17 commandments of YOLO-Driven Development.

Behold, YOLO Driven Development!

# Do not refactor, it is a bad practice. YOLO # Not understanding why or how something works is always good. YOLO # Do not ever test your code yourself, just ask. YOLO # No one is going to read your code, at any point don’t comment. YOLO # Why do it the easy way when you can reinvent the wheel? Future-proofing is for pussies. YOLO # Do not read the documentation. YOLO # Do not waste time with gists. YOLO # Do not write specs. YOLO also matches to YDD (YOLO DRIVEN DEVELOPMENT) # Do not use naming conventions. YOLO # Paying for online tutorials is always better than just searching and reading. YOLO # You always use production as an environment. YOLO # Don’t describe what you’re trying to do, just ask random questions on how to do it. YOLO # Don’t indent. YOLO # Version control systems are for wussies. YOLO # Developing on a system similar to the deployment system is for wussies! YOLO # I don’t always test my code, but when I do, I do it in production. YOLO # Real men deploy with ftp. YOLO

Forget those old pagan traditions of test-driven development and behavior-driven development. A new methodology every day keeps the IT consultants away! Ruby.zigzo summarizes this YDD manifesto as follows: “this is a joke, don’t do any of this stuff… or do it! YOLO!”

However, a simple GitHub search for “because YOLO” delivers over 600 hits, proving that numerous developers have already begun adopting the YOLO approach:

(map(lambda __suchwoow:\ map(lambda __because___yolo__:\ __lololol_.__setitem__(( (__because___yolo__)) , (0)), range(2*(__suchwoow), ((very_math)), __suchwoow ) ),

Oh no you didn’t…

So YOLO Driven Development isn’t your style? Okay, here are a few more hilarious IT methodologies to get on board with.

The Pigeon Methodology

Boss flies in, shits all over everything, then flies away.

ADD (Asshole Driven Development)

An old favourite, which outlines any team where the biggest jerk makes all the big decisions. Wisdom, process and logic are not the factory default.

NDAD (No Developers Allowed in Decisions) Methodology

Developers of all kinds are strictly forbidden when it comes to decisions regarding entire projects, from back end design to deadlines, because middle and top management know exactly what they want, how it should be done, and how long it will take.

FDD (Fear Driven Development)

The analysis paralysis that can slow an entire project down, with developments afraid to make mistakes, break the build, or cause bugs. The source of a developer’s anxiety could be attributed to a failure in sharing information, or by implicating that team members are replaceable.

CYAE (Cover Your Ass Engineering)

As Scott Berkun so eloquently put it, the driving force behind most individual efforts is making sure that when the shit hits the fan, you are not to blame.

Are there other curious methodologies that we forgot to mention? Please share them in the comments!