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".
Fuckit Driven Development; when you're tired of your manager making nonsense decisions and not respecting your expertise so you give up caring and blindly do what they ask in order to avoid arguments.
SNADWFYGDA (smile, nod, agree then do whatever the fuck you were going to do anyway); when you're tired of your manager making nonsense decisions and not respecting your expertise so you give up caring and do whatever the fuck you want as he won't read the code anyway.
Tried this and it never worked, later now i know why because manager speaks to me (human) whereas i have to speak to computer(no margin for ambiguity). The best thing is to be polite, listen and be humble and think yourself as a object flowing in the river. Never show anger a slightest bit. But once the attack starts personal, just ignore and look down as speaking to a complete idiot. This is not the best thing but it has worked very well for me.
I work in a monolith driven development environment.
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 :).
I largely agree with you. The challenges with this largely fall on the business side. I've once worked at a place where a customer agreement was structured in such a way that tied up our development and QA resources for resolving issues for them that weren't due to a fault on our product. For a small company of ~10 developers, we spend an awful amount of time tying up resources on tracking down issues that ended up being bugs in their own software; they just happen to discover them while using our product. And we really didn't get all that much money from them, either. It's not uncommon for a small startup to tie themselves up with a poor customer agreement for the sake of name recognition or misplaced hope in the agreement opening doors down the road.
CDD is when a customer is convinced to buy very expensive software that amounts to nothing more than a cosmetic upgrade to their existing broken process.
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.
Yeah, I've seen that. It goes along with the attitude that we won't deal with any problem, no matter how bad, unless an important-enough client screams loudly enough.
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.
Or when you have a large, old codebase, Fear Driven Development means touching the code as little as possible for fear of breaking something that's huge, complex, 10 years old and largely undocumented, which nobody understands. This often results in the kludges becoming the majority of the code, and any actual knowledge of the system existing only in corrupted form in gray matter.
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.
JITD (Just in time development): where you know that you aren't going to get specs that match the data you'll eventually need to parse, so instead of writing the code to do it you just wait until you get the actual data file and then bang out the code to parse it an hour before you're supposed to demo.
TDD (timecard driven development) - hack on shit for a while. commit at 4 PM. you may not be able to separate features, but you can back code out to the most recent "runs" commit before the rollback you need!
Imagine there's no compilers,
It's easy if you try{it()}
No stack below us
Above us only jit,
Imagine all the hacked source
Living for today... Aha-ah...
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
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".