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?
> <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.
> <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??
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.
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.
> > <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??
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.
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...
Previous Topic
