- 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.
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'.
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.
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
. 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?
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
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.
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
See also GoldPlating