[Retric]

I think people may be reading this backwards. I am specifically saying don't try as hard. Don't think about unit tests or anything else when writing correct code for a function.

Once you can generally write mostly correct code then you can work on improving your process. But, until most of your functions are working when you right them just work on improving that.

Edit: And yea quality may drop as part of this transition, but you need to get a feel for how much you can pay attention to.

[dpark]

You’re saying that if you have a problem with code correctness, the solution is to just try harder to write correct code.

The tests are there specifically to help find the errors that “trying harder” didn’t catch. You don’t get a higher quality result by cutting QA.

[Retric]

I don't necessarily think he has a problem with code correctness after QA. I think he has a problem with code correctness before QA.

You can build a factory that has a Great QA process that finds all faults and corrects them. But, inside the factory you still want to minimize the amount of defects for QA to find. Either way you still need QA, but it's easy to get into the habit of improving QA vs improving the initial process.

PS: One exercise I did for a while was every time I found a non syntax bug in a function I just wrote (aka bug at run-time) I would start over and rewrite it. It's painful, but 'Build' wait let's look at this again if I hit run and it does not work that's going to be painful. So is this actually correct? Anyway, doing that showed me how important it was to just focus on the code (and what it means) to exclusion of everything else.

[dpark]

If you drive improved quality into the initial product phases in a factory, that’s still QA. QA is not an independent process unless management is incompetent.

But you will not drive significantly higher quality into earlier phases by telling your factory workers to try to do a better job. You drive higher quality by analyzing where your processes are failing you and changing them so that they no longer do.

If your workers are consistently failing to tighten bolts sufficiently, you can add a QA step to check the bolts every time, or require your workers use a torque wrench, or use a robot to make this more consistent. But you have to do something other than telling them to try harder. You undoubtedly told them to try harder already and it didn’t work. Now you need better tools or processes.

[Retric]

QA let's you build a robot to tighten a bolt, then build a robot to test the bolt is tightened and repeat as needed. It's inherently output focused.

However, the lady designing the factory in the first place should know if tightening bolts or using an arc wielder has more issues. So sure, QA should include checking the oil level inside a robot in the factory to avoid problems in the first place. But QA is not all inclusive it's not for example part of the collage education that's training your workforce other than perhaps a requirement that they have said degree.

[dpark]

I'm not sure what you're trying to get at. Production is output focused.

QA is the system of trying to produce at the desired quality. Anything done to improve quality is QA, including whether you hire better employees or train the ones you have. You can define QA more narrowly if you like, but then we're arguing semantics and we're already off in the weeds.

[curun1r]

> until most of your functions are working when you right them

Heh...irony alert. You're advocating focusing on just getting it right the first time and you didn't get write right.

But seriously, the people you're responding to are correct. Any process that relies on humans being less error proneis bound to fail. You need to either create a process that makes humans less error prone (e.g. checklists) or embrace our propensity for making errors and plan for that eventuality.