Do The Most Complex Thing That Could Possibly Work

I prefer to program, rather than to refactor.
I prefer to program, rather than to think.
I think any problem can be solved with one more line of code.

Therefore:

I write programs that are TheMostComplexWhichCanBeMadeToWork.
If the program doesn't work, I add more code to it until it does.

In other words, I write a BigBallOfMud

This reminds me of Harrison, the man who invented the first accurate clock (for use at sea) in the book Longitude. He was one for running over his mistakes with more and more parts so that his 'mistakes' were no longer 'mistakes'. -- MatthewTheobalds

As explained in more details at JohnHarrison, the above is a gross misrepresentation.

He was trying to accomplish something that had never been done.
He effectively made successive prototypes to solve the new problems thrown up by his most recent prototype.
When he understood all the issues well enough, he produced a working solution.
- I think that mentioning JohnHarrison on this page in this way is nothing short of iniquitous. I'll leave it to others below to explain more clearly just how wrong the above characterisation is.

Working on his own - and against very powerful opposition and the received scientific wisdom - JohnHarrison managed to solve the greatest technological challenge of his time. When his solution was rejected, he solved it again. And again.

I think I would want to solve the greatest technological challenge of my time at least once before I started criticizing Harrison's methods - which, from my reading of Longitude, were considerably less complex than those advocated by his rivals - but then I long ago gave up being a cynic. -- TomKreitzberg

Don't get me wrong. I wasn't criticizing his methods, I was merely commenting on their similarity with this page. It will take me a long time to start criticizing the methods of anyone with that level of ability, good character and determination. -- MatthewTheobalds

Compare to DoTheSimplestThingThatCouldPossiblyWork. In this method, you think up the most hare-brained scheme that could possibly solve the current problem. For instance, if you need some user configurable script files, you don't go to an existing language like PythonLanguage or PerlLanguage. You develop your own language, then write a compiler for it, taking over a year of development time.

That's how Java was born.

But isn't that how a lot of other things die?

EverythingDies?.

The title would suggest someone doing something because they believe that complexity, a priori, improves code.

The way TheResidentCynic puts it reminds me of MakeTheSmallestChangeThatCouldPossiblyWork -- keep piling kludges on it until the problem seems to go away. Or maybe it's "don't refactor, ever" -- just keep plowing blindly on, and if you have a design flaw, add something else that compensates for it. In my experience, both of these most commonly arise from time pressure -- you don't revisit the design because you don't feel you have time to. (One might ask, "do you have time not to?")

You might also want to DoTheMostComplexThingThatCouldPossiblyWork if you mistake complexity for quality. That might come from a failure to apply YouArentGonnaNeedIt, adding unnecessary "flexibility" to a program. PrematureOptimization might be a related practice.

-- PhilGroce

Of course, TheResidentCynic didn't make any arguments for this actually working better, he just said he prefers it, and prefers not refactoring, and prefers not thinking, and prefers not debugging.

He did make the unsubstantiated claim that adding code can fix any bug, but note he didn't say he preferred working code.

So apparently he's just saying he prefers enormous kludgy buggy programs that get worse over time. Perhaps he's an insane conceptual artist.

"You see, it's a metaphor for the human condition. The rest of you who prefer code to work are just slaves to The Man. Sheep, all of you!"

As opposed to: DoTheMostComplicatedThingThatCouldPossiblyWork