How Canning Pears Is Like Coding Software (or Why It SHOULD Be Like It)
Today I donated 4 and 1/2 hours of my time to helping out in a cannery owned by my church
. The cannery has two sections, a dry pack cannery where they package sugar, wheat and other dry goods, and a wet cannery where they do items ranging from beef stew and spaghetti sauce to peaches and pears. Today we were doing pears.
After going through training and instruction on the safety procedures, I got cleaned up and suited up with a hair net, gloves, and apron. My shift on the floor started about 12:30 pm, there was an existing crew in place, I took over a position that was occupied by a women whom I would guess was in her late 50's. The line never stopped. The crew I was with just replaced the previous crew without haste. And the same went for when my crew was relieved 4 hours later.
During my shift on the floor I had a lot to think about. The machinery in the room made it too noisy to carry on a conversation with any of the others working around me, and music players are not allowed because they want your full attention on your task so that quality doesn't suffer. So this time I had alone I thought of two things: 1) Was I in any way at all helping those effected by Katrina
or those soon to be effected by Rita
? (I have not yet answered this, but I do know that my church is involved
in efforts to help) and 2) Coding software.
I do not know the entire process of how the pears are prepared and canned, but from what I gather it's something like this: Pears are loaded into a fancy machine where they are automatically cored and skinned. Then they go down a conveyer belt where they are manually reviewed and attended to. Then they are washed. Then they are put into a container. Then juice is added. Then they are sealed.
My specific task today was on the conveyer belt. We would attend to the pears as they came by, removing skin that wasn't automatically removed, and cutting out any bruises or bad spots on the fruit. Then once the pear was ready, we moved it onto a different section of the belt. Here is a simple layout:
As the pears would pass each worker the unreviewed pears section would get thinner and thinner, and the reviewed pears section would get more and more full, as I brilliantly illustrate here:
As you are tending to cleaning up the unreviewed pears, you can't help but notice flawed pears that were okayed and moved into the good section. So you remove those pears and clean them up and move them back. Peer review. Quality assurance checking. As it flows you go from the 1st pair of workers performing 0% peer review, and 100% new pears... down to the end of the line where hopefully the pears have all had their 1st review so the end workers are doing 100% review, and 0% new pears.
An opposite approach might be as follows where each worker operates his or her own independent line separating good from bad and performing the required cleaning, but their decision is final and never reviewed:
Obviously you can see why the peer review is necessary. If not, you should go can some pears and see how many that still have seeds are moved into the approved section.
Now, think about software. The same approach needs to be taken to release a quality product. It's nearly impossible for a single person to release 100% quality work (even more so when said person is under time constraints).
Case in point:
In yesterday's blog entry on passwords, I linked to a bookmarklet written by Nic Wolff that would generate unique passwords on a site per site basis just by clicking a button in your browser. Genius eh? Well while it works and it is great (I have been using it for over 6 months myself), it's not perfect.
And on Chris' site he gives credit to Tim Cuthbertson who found a flaw with handling second-tier top-level domain names. And Chris states that his fix is not perfect and why it's not perfect, leaving room for anyone with input to go ahead and provide the input.
Now the situation I just described above is an excellent example of peer review, but the crazy thing is that none of these guys work together at a company or are affiliated with each other, they just all participate in what can be considered the open source
Tim Cuthbertson might not even be a programmer himself. But that's OK. In the open source community under the Bazaar model Users should be treated as co-developers.
In a perfect world, companies would have a good peer review system in place on all projects. But unfortunately it doesn't happen. I have had QA on some of my projects - but not all. And I have been the QA on some of my co-worker's projects - but I wasn't on all of them.
I am starting to think that about the only place you can have ultimate quality assurance is in an open source environment - where your review team is as large as your user base, not just the staff you can afford, or friends you know.
My good buddy Mike
recently did something somewhat unique to himself when he opened up a game
he was working on to the public at large earlier than what he normally would do. And he opened with with a forum encouraging as much feedback as he could get. And I think overall it really helped his project. He had tons of feedback regarding bugs, and features that people wanted to see. It's much easier to add new features when you are in active developement. Imagine spending 2 months coding a project, and then in your head "finalizing it". Then when you release it to an audience all you get is a big fat list of changes.
But again referring to the Bazaar model, if you release early and constaintly integrate updates and listen to the user (they are equal to you), you can roll with the changes and in the end have a better product.
Currently there are no comments.
You can be the first!