Nathan Bowers pointed me to this five year old Cool Tools entry on the book Art & Fear.
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html
This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2008/08/quantity-always-trumps-quality.html
Does the same principle apply to blog content?
1 Like
Read the paper Unskilled and Unaware of It: How Difficulties in Recognizing One’s Own
Incompetence Lead to Inflated Self-Assessments.
Practice only improves the product when the practitioner knows the difference between better and worse. Some people need outside feedback, with good and bad pointed out to them. Really. Read the paper, then reconsider your own incompetence. It’s a useful exercise.
Also consider the insult, He can write FORTRAN** in ten different languages. This is like someone else who mentioned 1 year of experience repeated 10 times over.
** FORTRAN is only representative of any language with weak or byzantice control structures, little or no data structuring, etc. FORTRAN IV had computed GOTO, line-number labels, implicit loops denoted by line-numbers, and other features now considered actively harmful to good coding. Substitute any other disparaged language.
Wow, this blog post is so bad that it should be criminal.
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.
I had a job once. It was a bad job; it was before I’d learned to be at all discriminating about the jobs I took. One day, I was gazing out of the window, into the middle distance, trying to work out some network protocol issue in my head. Big Bossman (you know the type: sales guy who made a startup with his docile techie buddy) happened to be passing and said, You! What are you doing?!; to which I replied, I’m thinking, Big Bossman. His reply became a standard catchphrase in the office:
You’re a programmer! I don’t pay you to think!
Evolution is another analogue to pottery or software coding. Evolution requires a lot of begetting ( making lots of pottery or writing lots of code ) and requires selective pressures to push the begotten to be better.
For pottery, the selective pressure might be your own satisfaction with the final artifact, comments by others, or the satisfaction of paying customers.
For software coding, the selective pressure may come from your own satisfaction with the code you wrote, software testers, bug reports from users, or competing products.
It’s pretty plain here that the analogy it about making lots of iterations so you’ve got a good cycle happening. I’d also say the same logic also applies to project experience. Don’t stay on just one project for more then 2 years - try a few different ones out rather then just theorizing over how to improve the one you’re currently on. Whilst it is possible to improve some projects if the attitude is right from the managers perspective, sometimes it’s a lot less stressful to just part ways amicably and find one which better adheres to your principals of whatever you think is good in development.
One thing the story doesn’t say was whether the students were producing better stuff at the end or just a few random good pieces.
I think also putting pressure on the students also emphasizes making easy wins where possible. People remember what worked well from the last piece and what kind of aesthetics took far too long in terms of bang for buck. Unless time is regarded as a finite resource, our approach will be skewed.
Okay, but only 'cause quantity leads to quality better than quality itself, you can’t say something like Quantity always trumps quality. It’s somehow very, very wrong and to be honest it’s kinda stupid too. It sounds like a bad advertising slogan to me.
But, now that i got that out of my system i totally agree with the contents of the post. The misleading title just bugged me really, really much.
I definitely agree. As a student I’m well-aware that quality flies out of the window when a deadline looms closer, yet the work always comes out perfectly once enough power is thrown at it.
I’ve always compared learning to write good software to learning to play the guitar. You start out really badly, some good advice will get you going along very slowly, but given the standards (chords, scales, etc) and enough practice you’ll be able to play loads of songs.
When learning the guitar I put the theory book down and started playing non-stop and now I play pretty well. I’m yet to be a ‘good’ programmer but given the practice I’ll get there.
The definition of quality is missing. I know many people who have written a lot of source code, learned from mistakes, but still write crappy source code that triggers lots of bugs. The missing part is the urge to meet quality standards.
Quality standards vary a lot by purpose: Washing machines, satellites, hardware drivers, middleware, database GUI applications, reports etc.
An extremely good GUI programmer may not have the skills to write good enough quality for a satellite, and an extremely good satellite programmer may not have the skills to write good quality GUI applications.
Iterate, Repeatedly, Again and Again.
So write terse code, don’t use comments and now don’t waste time designing, just code?
Has the engineering approach run it’s course?
Are we harking back to the ways of old school hackers?
Or is it just Jeff?
Point taken of course. However, I do not agree that calling writing software as an ‘engineering’ activity is generous.
I think its fairly engineering like when you have to write software.
Come to think of it, back in college we had entire subjects around software ‘engineering’.
I hope you aren’t writing code for the Space Shuttle.
Or any major bank.
Or a hospital.
Or for a nuclear reactor control system.
Or for an air-traffic control system.
Or for the combat systems aboard a F22.
Etc.
Quality matters a lot, methinks. Maybe not if you are hacking together some marginal web app, but in a lot of places it is king, and needs to be.
I also think security = quality too. That’s something else to think about here.
Ah, the hacker mentality. Keep on trying until it works rather than spending some time to leaf through a manual and implementing a fix for the problem in less than five minutes.
It’s not even true for pottery (all forms of pottery more complicated than the crudely decorated blobs of the early stone age were learned from others, not arrived at through trial and error) let alone for something more complicated like writing or developing software.
Just don’t keep writing the same thing over and over again or you won’t improve. There is limited learning in the array of possible mistakes you can make while writing an order entry system.
Learning from your own mistakes might allow you to achieve some form of local maximum, but learning from others, from books, or just theorizing is necessary if you want to improve past your own neighborhood.
This pretty much holds true for everything. I’m a photographer and every professional photog I know chants the mantra you must shoot to get better.
I kind of assumed this article would talk about quantity vs. quality in terms of the number of shareware programs you create. I wrote one high-quality program in the past few years and have maintained it for a while, and barely make any money. I know a few other people who slam out one shitty program after another and make so much money that they live off of it and have plenty to spare.
Perfectionists have it hard…
I think the point is how get someone better at programming, it’s not about the project themselves. Later designs performed by those programmers are made based on first-hand programming experience, previous mistakes and successes, not on theoretical assumptions.
For instance, a project analysis done by someone with little experience ought to focus too much on non-issues, while more serious but still expectable problems are completely forgotten. It’s not about despising design, it’s a critique of design done on theoretical assumptions. If there’s not enough experience on the field available, prepare for incremental design instead of big-design-up-front.
Has the engineering approach run it’s course?
Are we harking back to the ways of old school hackers?
In research engineering, you try lots of cheap things and see what works. If you already have software which does the job (production engineering), then you don’t write new - though configuring and customising an existing product for a specific system may be a multi-year exercise for a large team.
Coding for pleasure or to learn, I’d agree that doing lots trumps theory - I learnt much more trying to write compilers that I did reading the theory.
It’s not the same as not reading the manual - firstly, when learning, reading the manual doesn’t ingrain the information, and secondly, when developing, there isn’t a manual for the code you’re writing. But if you’re configuring an existing product or plugging into an API, then reading the manual is a very good idea - before you write a throw-away test case to find out whether the product does what the manual says. In my experience, most of the non-trivial fixes for things with have manuals are for things not mentioned in the manual, or where the manual is wrong.
After the learning/developing stage, there should still be a stage of refactoring to convert a prototype to a product, so it can be maintained if the original team gets hit by a bus, or can be put down and picked up a year later (it’s been company policy most places I’ve worked that members of development teams travel to meetings in separate vehicles to prevent losing what’s in their heads in event of accident, but once something gets productised the knowledge should have been documented, and the code refactored so any contractor can maintain it).