Asshole driven development (2007)
scottberkun.com
scottberkun.com
The entire code base must be comprised of purely copy-and-pasted code examples from SO. No typing allowed. This actually may be an interesting challenge!
MIJDD: Machete In Jungle Driven Development.
Start down an initial path to solve the problem, and then never back-track, turn around, or admit it may be the wrong way despite how many swamps, cliffs or deadly bugs you run into. Also known as "BAWM", or "Burke And Wills Methodology".
PEPDD: Prototype Equals Production Driven Development.
If an initial attempt at writing the code compiles and seems to do the job, don't worry about debugging or refactoring, just ship it, start charging the customers, and start bolting on new features ASAP. Also known as "Additively Deployed House Of Cards", or "ADHOC".
If it's been written by someone smart and has a lot of upvotes, it's probably better than most code.
There's an idea there ...
Despair Driven Development - It's clear the project/company is going to fail anyway, so hack on anything you want, it doesn't really matter.
Where you know that you'll leave the company by the end of the month and don't give a shit.
The application is now so huge, that rather than reuse code, team members just add new but very similar methods for new features, because you can no longer identify the code you should be reusing/tweaking for that new feature, because it's lost in a sea of shit code and complexity, maintained by multiple developers (some good, some bad, some awful) over the last ten years.
Closely tied to Customer Driven Development, where be features get developed because customers are willing to pay for the development, even if the change doesn't make much sense, or is being used to mimic a bad manual customer business process.
In fact, companies that do this are probably more successful than not.
Your customers are your source of revenue, 'what they want' is good for your business :)
In the early stages of a company, before mass market adoption, it makes sense for companies to please whoever they can before 'lift off' into broader adoption.
So many companies got their start this way. Microsoft, Oracle etc..
From an architectural standpoint, it may sometimes seem 'impure' but then you really do have to ask yourself what you are building and why :).
What you perceive as 'cosmetic' might be some really minor thing ... but it may be absolutely critical to your customers operational needs. Remember if you have zero IT ability than the smallest process change can be a huge pain.
Example: Customer Service may be a great chance for customers to give a heads up about things that are broken or needed features. CS Reps might hear about it all the time. But they have no way to log that information, or for it to be refined. Product leaders therefore are screwed: there most important feedback is lost.
With a small change to CSR, staffers can make note of things, put priorities, now if there is a 'blow up' in a release, product can know about it right away.
Very small change can mean big impact.
It essentially a fear of trying out best technology, or best practices or fear of visibility. situation where organization does not support a progressive environment instead everyone has been kept under some kind of fear or pressure to create shitty code.
It's also similar to the one described above where every time someone needs a piece of functionality, he just writes it, instead of searching for what already exists because, again, no one understands it.
It also goes hand-in-hand with SWDD, Squeaky Wheel Driven Development, where no matter how bad the code is, or how slow or unstable it is, nothing gets fixed unless an important-enough customer complains loudly enough.
It also goes well with the Fire Ready Aim Development where the teams spend 3 months developing new features and 9 months fixing them. Agile is supposed to help with this, but if you don't have a robust automated testing infrastructure, good documentation and at least a little coding discipline, it won't. It's not hard for Agile to become nothing more than taking your huge bug-fixing and hardening phases and breaking them down into two-week-long chunks.
Then there's ITWWSTD, It's Done When We Stop Testing Development, where you plant a stake in the ground and shop what you have because you've run out of time before you've run out of bugs.
Every class does only what's best for itself with no thought or concern given to any other class, any objects created are held on to privately forever and any object that needs something is considered a parasite.
Imagine there's no compiler It isn't hard to do Nothing to wait or segfault for And no undefined behavior, too Imagine all the users Running code sandboxed...
You may say I'm a dreamer But I'm not the only one I hope someday you'll join us And the world will be as one
Imagine no possessions