On Thursday, 4 January 2018 at 18:27:37 UTC, H. S. Teoh wrote:
So, one can choose to be part of the noise, or part of the real
work. If you don't like the way certain things are done, then
step up and do it differently.
I hear this argument too much in the D community. It is not the
solution D needs.
Plenty of people are willing to step up.
The problem, as I see it, is a lack of process to ensure such
peoples efforts are worthwhile.
I volunteer in the community (nothing to do with computing), and
I only volunteer with organisations that have clear strategic
goals, well defined processes, and good management. These things
form a vital framework that encourages and retains volunteers,
and the best of them too.
The open souce development model is all about volunteers... I get
that...but from what I can tell, it often lacks such a necessary
framework... and this becomes self evident over time.
I do not see it as the responsibility of volunteers to create
such a framework. This should be motivated and sponsered by core,
just as it would in a real world scenario.
And how are you measuring software quality?
By looking for that essential framework I mentioned previously.
I see this a problem for the D Foundation to address, and not
something left up to the randomness of the open source
development model.
That's a decision for the D Foundation to make, not for us.
Indeed!
Nonsense. All real-world software have thousands of bugs. If
you're lucky, that is. Most have a lot more than that. Today's
software is complex enough that many of these bugs are
non-trivial to fix. It does not necessarily correspond with the
lack (or not) of QA.
Rubbish. QA and number of bugs are correlated.
You seem to have an overly-simplified, idealistic view of QA.
In my experience, the existence of a QA department does little
in terms of actually eradicating bugs from software. What it
does, especially in an enterprise environment, is to encourage
coders to hide problems because they don't want the QA people
to constantly be breathing down their necks about long-standing
bugs that are non-trivial to fix. It's either that, or they are
motivated to implement quick-n-dirty hacks instead of
addressing the fundamental problem, because they just don't
want to deal with the issue right now and implementing hacks
instead of real solutions keeps the bug count down (makes them
look good and makes the managers happier), keeps QA off their
backs, and keeps them on schedule against unreasonable
deadlines.
Those coders are working for the wrong company.
Now I'm not saying D doesn't need to improve its QA process --
that would be quite welcome, in fact.
Finally! We agree!
Unfortunately, the fact of the matter is that software is
complex, and especially in this day and age, of a scale where
the complexity is beyond an ordinary person's ability to fully
grasp. Anyone who tells you otherwise has no idea what they're
talking about, and/or is trying to sell you snake oil.
Hence the need for QA.
When you have a whole bunch of people contributing changes, the
existence of bugs is almost an inescapable fact.
Hence the need for QA.
One can look at this from the pessimist's point-of-view, that
all software is hopelessly buggy and we might as well give up
now, or one can look at this from the opportunist's
point-of-view, that there is much room for improvement, much
room to make meaningful contributions, and much space to go
much farther than we already have.
QA is optimistic, not pessimitic.
