The Artima Developer Community
Sponsored Link

Weblogs Forum
Jeff Atwood on Quality versus Quantity

7 replies on 1 page. Most recent reply: Aug 15, 2008 8:00 AM by d potter

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 7 replies on 1 page
Frank Sommers

Posts: 2642
Nickname: fsommers
Registered: Jan, 2002

Jeff Atwood on Quality versus Quantity (View in Weblogs)
Posted: Aug 6, 2008 6:22 PM
Reply to this message Reply
Summary
In his popular blog, Jeff Atwood suggests that becoming a great developer has more to do with the quantity of code you produce than with an explicit desire to produce high-quality code from the start.
Advertisement

In a recent installment of his popular blog, Jeff Atwood writes that when desiring high quality output, focusing on quality can be counter-productive. Instead, Atwood says that a focus on quantity, rather than quality, can lead to better results:

Quantity always trumps quality. That's why the one bit of advice I always give aspiring bloggers is to pick a schedule and stick with it. It's the only advice that matters, because until you've mentally committed to doing it over and over, you will not improve. You can't.

When it comes to software, the same rule applies. If you aren't building, you aren't learning. Rather than agonizing over whether you're building the right thing, just build it. And if that one doesn't work, keep building until you get one that does.

While I do think that some amount of agonizing—thinking through and doing some up-front design—is absolutely necessary for high-quality results, such results seldom come about purely because of the initial design. Rather, as most recently Scott Bain writes in his wonderfully written Emergent Design: The Evolutionary Nature of Professional Software Development, the best design emerges from the codebase itself, over some period of time—perhaps as a result of refactoring, re-architecting, or even a re-write (the latter, however, is a dangerous proposition, and may not lead to improved quality). That suggests that for quality to emerge, some codebase needs to exist in the first place, and that one way to achieve high quality code is to keep tending to that codebase.

What do you think of Atwood's suggestion that when desiring great quality, a focus on quantity is more important than a focus on quality itself?


James Watson

Posts: 2024
Nickname: watson
Registered: Sep, 2005

Re: Jeff Atwood on Quality versus Quantity Posted: Aug 6, 2008 6:44 PM
Reply to this message Reply
> <p>What do you think of Atwood's suggestion that when
> desiring great quality, a focus on quantity is more
> important than a focus on quality itself?</p>

I think his point is absolutely correct but the above isn't really the essence. I think actually the point of the blog will be hard to understand if you don't already get it.

I think you could sum the blog up with the old saw "practice makes perfect". I think the point is that it's the number of solutions you come up with, not the lines of code you produce.

I think there's a larger point here that you can't just divide development into designers and coders which is an idea I find too popular as of late.

robert young

Posts: 361
Nickname: funbunny
Registered: Sep, 2003

Re: Jeff Atwood on Quality versus Quantity Posted: Aug 7, 2008 5:11 AM
Reply to this message Reply
> <blockquote>
the best design emerges from the
> codebase itself, over some period of time—perhaps as
> a result of refactoring, re-architecting, or even a <a
> href="http://www.joelonsoftware.com/articles/fog0000000069.
> html">re-write</a> (the latter, however, is a dangerous
> proposition, and may not lead to improved quality). That
> suggests that for quality to emerge, some codebase needs
> to exist in the first place, and that one way to achieve
> high quality code is to keep tending to that codebase.
> </p>

Good God. If there were true, then windoze would be ruling the World of Quality. Here's the truth: since all but Joel Spolsky ignore the Prime Directive, sunk costs are irrelevant to decision making, once the bad design has been committed to text, it lives on forever. Why do you think there's still XX billion of lines of batch COBOL code masquerading as SOA??

Raoul Duke

Posts: 127
Nickname: raoulduke
Registered: Apr, 2006

Re: Jeff Atwood on Quality versus Quantity Posted: Aug 7, 2008 11:39 AM
Reply to this message Reply
i think, as should anybody with a grain of sense (i'm being somewhat facetious :-), that as with an awful lot of things in life, "it depends". you can probably find instances of groups in real life who 'prove' any particular side. i'm sure companies have folded before they wrote code because they thought too long whereas their competitor just hit the ground running. i'm also sure i've seen code that was perhaps slowly killing a company because the code was written asap.

might be worth thinking about from a sort of design patters perspective: you have to enumerate the forces / conditions / requirements / limitations you have in place, and then you can figure out how to dial in a not-entirely-suckful approach. of course, nothing is ever perfect and ideally you will iterate. but having a fundamentally non-suckful start is a good thing in my book.

Bruce Eckel

Posts: 875
Nickname: beckel
Registered: Jun, 2003

Re: Jeff Atwood on Quality versus Quantity Posted: Aug 7, 2008 1:05 PM
Reply to this message Reply
There are many variables in the process of becoming good at developing software, and to say that this particular one, the amount of code you write, is the true important factor, seems a bit oversimplified.

I've seen people write reams of bad code. Lots of it, and they seem to repeat the same mistakes year after year. Writing lots of code doesn't seem to help.

Personally, I believe you have to think about what you're doing and consciously try to constantly improve your process. If you're doing that, then writing lots of code helps, but if you aren't, the quantity is meaningless.

Dick Ford

Posts: 149
Nickname: roybatty
Registered: Sep, 2003

Re: Jeff Atwood on Quality versus Quantity Posted: Aug 7, 2008 5:04 PM
Reply to this message Reply
> > <blockquote>
> the best design emerges from the
> > codebase itself, over some period of time—perhaps as
> > a result of refactoring, re-architecting, or even a <a
> >
> href="http://www.joelonsoftware.com/articles/fog0000000069.
>
> > html">re-write</a> (the latter, however, is a dangerous
> > proposition, and may not lead to improved quality).
> That
> > suggests that for quality to emerge, some codebase
> needs
> > to exist in the first place, and that one way to
> achieve
> > high quality code is to keep tending to that codebase.
> > </p>
>
> Good God. If there were true, then windoze would be
> ruling the World of Quality. Here's the truth: since all
> but Joel Spolsky ignore the Prime Directive, sunk costs
> are irrelevant to decision making, once the bad design has
> been committed to text, it lives on forever. Why do you
> think there's still XX billion of lines of batch COBOL
> code masquerading as SOA??

What is ruling the world of quality?

Keith Ray

Posts: 658
Nickname: keithray
Registered: May, 2003

Re: Jeff Atwood on Quality versus Quantity Posted: Aug 10, 2008 7:00 AM
Reply to this message Reply
My experience is that these three things lead to writing better-quality code. There are other things, but these three stand out in my experience.

1. Reading code that other people wrote, and reflecting on it. You get this "for free" if your team does code reviews or pair programming and you pay attention to what makes the difference between good, understandable code and the opposite. Read open-source code and its tests and examples.

2. Write tests for existing code. Write unit tests for your own code or other's code, and pay attention to how easy or difficult it is to thoroughly test different styles of coding. (You'll need to learn about fake/stub/mock objects to thoroughly test object oriented code.) You should find that old maxims about cohesion, coupling, static/global variables, and using interfaces instead of concrete classes, and even separating construction from usage, start making much more sense as they enable testing (and thus "re-use" of classes in tests.)

3. Becoming aware of duplication while test-driving code. If you TDD new code, and many of your tests are almost identical, that's a signal that you're missing some abstraction that would eliminate that duplication. Test-Driven Development has a refactoring step: here an education on code-smells is important... detecting and eliminating the Duplicate Logic code smell is very important for improving the design, but also reflecting on anything that seems repetitive or brainless or inaccessible or difficult. Having a peer review or pair programming partner helps a lot with this. Pair programming provides the faster feedback and has more opportunity for learning.

d potter

Posts: 5
Nickname: ifatree
Registered: Aug, 2008

Re: Jeff Atwood on Quality versus Quantity Posted: Aug 15, 2008 8:00 AM
Reply to this message Reply
I think the point Atwood makes (even just reading the quote provided without context) is about "coder quality", not about "code quality" of a particular project. Writing more blog entries won't make the crap entry you wrote last week better, but it will make the entry you have to write next week better. Same with code.

>Why do you think there's still XX billion of lines of batch COBOL code masquerading as SOA??
well, the real answer is "budget", but also likely because the original COBOL coders (or at least the maintainers) knew what the hell they were doing. and they knew that because they had seen and written a lot of their own code before.

on the point that you need to sit down and think about a system before you develop it, that's not what Atwood's arguing against. of course you have to do that to some extent. he's alluding to the fact that if you haven't ever seen "X, Y, or Z" techniques for solving a problem or have never had to write code to solve the problem yourself, you're not likely to come up with the best answer just by thinking about it in isolation. you have to throw some classes together and see how you can make them interact.

how do you "avoid premature optimization"? stop overthinking and start coding...

Flat View: This topic has 7 replies on 1 page
Topic: Thinking in Patterns Workshop in Sao Paulo, Brazil Previous Topic   Next Topic Topic: Interview on The Flex Show

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use