Quantity Always Trumps Quality - Short But True Blog Post

[mouser]

Jeff Atwood at Coding Horror hasn't been putting out his best work on the Coding Horror blog lately, probably because he's focused on his new Stack Overflow project which will have its grand opening soon, and today's post isn't really saying anything new, BUT it is saying something that everyone needs to hear about the central importance of just being productive..

Well, came grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the "quantity" group was busily churning out piles of work - and learning from their mistakes - the "quality" group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

http://www.codinghor...archives/001160.html

[Deozaan]

Nice article. Especially if you read the 3 other articles listed.

[f0dder]

Haven't looked into the three linked articles, so I can only comment on the main idea... I do agree you shouldn't be over-thinking solutions, but "Stop theorizing." (that sentence standing alone) can be dangerously misleading. Most projects do need some theorizing/thinking-through before you start mindlessly churning out code. Otherwise it's way too easy to code yourself into a corner where you have to do massive re-factoring (or starting from scratch).

Sure, that can be a valuable learning experience as well, and not too bad for small hobbyist projects. But a little thinking and planning and specification goes a long way if you want to work on anything larger than tiny-size

[cranioscopical]

Most projects do need some theorizing/thinking-through before you start mindlessly churning out code. Otherwise it's way too easy to code yourself into a corner where you have to do massive re-factoring

-f0dder (August 03, 2008, 03:02 PM)

The voice of reason!   

[Stoic Joker]

Having worked on several database oriented projects, I gota go with f0dder on this ... GumBalling code together is a total catastrophy.

Sure there is a break point where you need to just bite the bullet and try something ... but think it through first.

[mouser]

Don't get me wrong, it's not that a project doesn't need planning -- I've written before about how that can often be the funnest part.

I think the main point could be phrased simply: Be productive.  Create things.  Don't just think+talk about making the perfect thing.  Create imperfect things, and in doing so you will learn to make better things.

It's not that you shouldn't plan and learn, and theorize -- it's that you have to know when these activities are becoming and excuse and a hindrance to actually getting something done.

And most importantly, you have to realize when you are at the inflection point where actually jumping in and starting to work on the imperfect version (perhaps just a prelude and a planned throwaway first version) is the faster road to learning than trying to solve the problem before you begin.

[f0dder]

And that I agree with, mouser - I just think it's important to spell it out as clearly as you did, to avoid people thinking the point is to jump the gun and just hammer away at the keyboard

[mouser]

The counterpoint caution that probably needs to be said also is that:  if all you do is practice with your intuitive gut level skills, you will get very good at what you are doing but you might also pick up and ingrain in yourself some unhealthy habits that are a constant source of inefficiency and harm, and that you find very hard to break yourself from.

It's quite important that mixed in with practice is a healthy dose of caution and humility and appreciation for being taught new and better ways to do things.

[justice]

First version out of the door quick, second version provides more insight, third version might be ok. So you can see quantity as quick reiteration of projects.

[Deozaan]

I think everyone here would likely agree with the article if they clicked the link and read what he was really meant by "Stop Theorizing."

Here's the Stop Theorizing link, in which the following text is found:

Jeff Atwood quoting Joel Spolksy:

When you go too far up, abstraction-wise, you run out of oxygen. Sometimes smart thinkers just don't know when to stop, and they create these absurd, all-encompassing, high-level pictures of the universe that are all good and fine, but don't actually mean anything at all.

These are the people I call Architecture Astronauts. It's very hard to get them to write code or design programs, because they won't stop thinking about Architecture. They're astronauts because they are above the oxygen level, I don't know how they're breathing. They tend to work for really big companies that can afford to have lots of unproductive people with really advanced degrees that don't contribute to the bottom line.

Here's the key distinction between an architecture astronaut and a practical developer: when you're in the trenches proving your ideas by implementing them in real applications. The kind used by actual users.

-Jeff Atwood

Jeff Atwood quoting Christopher Baus:

Software isn't about methodologies, languages, or even operating systems. It is about working applications. At Adobe I would have learned the art of building massive applications that generate millions of dollars in revenue. Sure, PostScript wasn't the sexiest application, and it was written in old school C, but it performed a significant and useful task that thousands (if not millions) of people relied on to do their job. There could hardly be a better place to learn the skills of building commercial applications, no matter the tools that were employed at the time. I did learn an important lesson at ObjectSpace. A UML diagram can't push 500 pages per minute through a RIP.

There are two types of people in this industry. Talkers and Doers. ObjectSpace was a company of talkers. Adobe is a company of doers. Adobe took in $430 million in revenue last quarter. ObjectSpace is long bankrupt.

[mouser]

Whenever i read some quote that makes its argument by comparing one method that makes tons of money and the other that doesn't, it send up flags for me.

Even though i do believe strongly in the general argument being made here, i think it needs to be said: The goal in life is not to make the most money.  Just because one path makes you more money doesn't mean it's the right path to take.

It's almost certainly true that in the software world, the "best" code is almost never the code that makes the money -- making money on software probably has more to do with marketing than anyone wants to admit.  Does that mean the best way to be a "successful" coder is to stop reading programming books and start reading marketing books?

There is sooo much to be gained by theorizing and trying to think about the bigger picture and to break free from the daily grind to get something done now.  Just as it's not a good idea to spend ALL your time theorizing and planning without ever putting your ideas into action, it's also not good to spend all your time with your head down soldering things without ever taking time to theorize, dream, plan, etc.

[mouser]

Another way to express what i was trying to say:

A lot of people (as the quotes deozaan found) might tell you:
You should focus on creating concrete stuff because that's how to make your company successful, etc.

From my standpoint, it's the bigger ideas and the theoretical stuff that is much more interesting and valuable, BUT that you should also focus on creating concrete stuff because that is an important part to helping you develop and refine and test your theoretical ideas.