Intriguing post on Slashdot SQA professionals might be interested in:;cid=20136383

More interestingly to QA people is the top comment, I feel:

Programming is fundamentally a design problem. A great bridge designer doesn't do the work of ten lousy bridge designers; the great one designs one great bridge in the time it takes the ten lousy ones to design ten lousy bridges.

I think you hit the nail on the head there. Or maybe even more accurately, a great bridge designer designs a great bridge, they build it, done. A poor bridge designer designs a poor bridge, they start building it, turns out the design isn't working, redesign. Some changes to the bridge specifications screw the whole design because it's so inflexible, redesign. The performance of the design is too poor, redesign. Between the extra design time, wasted implementation time, wasted management time, status meetings, plan revisions and generally inefficient panic actions, I could easily see that being 10x the great designer's time.

[/ QUOTE ]

This made me ponder the existence of QA itself.
I would attest that QA is a (by?)product of poor planning in the programming process. Perhaps this is the reason why there is this shift to unit type QA -- better planning allows them to check as they go.
Anyone else agree? Is this the major factor in the existence of our jobs?

And this myth of the uber-programmer is essentially good planning. Whether it be a single person or a team.

I guess if we lived in a perfectly planned programming world
we QA people would be required in the planning process as well -- making sure usability and functionality is planned for. I guess that means we should start to get more involved into the planning stage now.

Thanks for reading my ramble.