• H. S. Teoh (103/146) Jan 04 2018 Me too. :-( Does anybody know what happened to him? He just sortof
• codephantom (25/67) Jan 04 2018 I hear this argument too much in the D community. It is not the

"H. S. Teoh" <hsteoh quickfur.ath.cx> writes:

On Thu, Jan 04, 2018 at 10:23:57AM +0000, Paolo Invernizzi via Digitalmars-d
wrote:
 On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:
 [...]

 
 I'm missing Kenji...

Me too. :-(  Does anybody know what happened to him? He just sortof
dropped off the radar suddenly and I haven't been able to find out where
he went or what happened to him since ~2 years ago.


On Thu, Jan 04, 2018 at 11:29:20AM +0000, codephantom via Digitalmars-d wrote:
 On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:
 It all comes down to who's doing the actual work vs. who's just
 telling others what they think they should be doing, which rarely,
 if ever, works.


[...]
 I think that view really needs to be challenged.
 
 Those who might be willing to contribute are probably not sitting
 around waiting for someone to tell them what to do. On the other hand,
 there may be legitmate reasons why they are not just getting involved
 and doing things.

I'm pretty sure there are legitimate reasons for not getting involved.
But the point is, at the end of the day, *somebody* has to do the work.
And since this is an open source project, we are all volunteers (except
perhaps for a few that are being sponsored by the D Foundation).
Experience has proven time and again that telling volunteers to do
something other than what they're currently doing just does not work.

You can have all the most legitimate reasons and the most sound
arguments, but the fact of the matter is, volunteers in an open source
project aren't going to do what you tell them to do; they're going to do
what interests them.  This isn't just in D; it's the general pattern
across the majority of open source projects.  The best arguments are not
worth much when it comes down to how much work is actually getting done,
which, at the end of the day, is what counts.

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. Usually, within reason, the result will be that you get
noticed, and then you get granted the privileges of making things
happen.  Or you can choose not to participate, which is perfectly fine,
but in that case nothing will change.  That's all there is to it.


 I suspect, and I could be wrong, that a lack of clear process could be
 a matter of concern. I also suspect, and I could be wrong, that
 working out where best to exert their effort is not as simple as just
 finding something that interest them.
 
 I also expect, that not everyone using D, or using these forums, need
 to be, or are equipped to be, contributors to resolving D's bugs. Such
 people should still feel free to express their concerns, without being
 told that they should go and do something.

You are always free to express your concerns. My point wasn't to
discourage anyone from doing so.  Just that doing so only rarely leads
to actual results.  Sometimes, if you're lucky, some sympathetic
volunteers will pick up the tab and do the work for you, but that only
happens rarely.  The way I see it is, I could choose to complain and
moan about why X, Y, Z aren't being done right in D, or I can choose to
dive into the work and actually get things done. One choice leads to not
much happening, and the other leads to change.  To me, it's only logical
to choose the path that leads to change, rather than the path that's
been proven time and again to be ineffective.  But that's just me.
*shrug*


 Software quality is more important than ever, as it can impact us in
 dramatic ways these days. D needs to have quality assurance process in
 place to ensure that D's repository of bugs are appropriately being
 assessed, categorised, prioritised, and actioned - and this needs to
 evident to all.  Then and only then, wil willing contributors be
 better positioned to make decisions about where to exert their effort.

And how are you measuring software quality?

If, and this is just pure speculation on my part, you're basing your
perception on the bug count, I'm sorry to be the one to break the bad
news to you that *all* software projects are full of bugs. If you're
lucky, they're "only" in the thousands. Most real-world software
projects have more than that, in fact, sometimes orders of magnitude
more.  Most proprietary software houses deal with this by simply closing
bugs they deem unimportant, or have been "inactive" for some arbitrary
amount of time.  This certainly helps to keep the bug count down, and it
certainly helps to make people feel good about themselves, but it does
not mean that the software has better quality. It just means that we've
willfully "forgotten" about the bugs that still exist.

My preferred approach, and I'm glad that D has been taking this
approach, is to be honest and admit that yes, there are still thousands
of open bugs.  The brutal fact is that *all* complex software have these
numbers of bugs, and one might as well admit to oneself that there's
room for improvement. Being honest with oneself and recognizing that
there are problems is the first step towards a solution, and an actual
increase in software quality. Sweeping things under the carpet ain't
helping the actual code quality any.

Furthermore, a good number of bugs in bugzilla are enhancement requests,
so they don't really represent flaws in the current implementation of D,
just that there's more room for improvement. If a piece of software ever
reaches the point where there's no more room for improvement, that's
when that software project is as good as dead.


 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.


On Thu, Jan 04, 2018 at 12:36:58PM +0000, codephantom via Digitalmars-d wrote:
[...]
 1000's of bugs suggest to me, a lack of QA.

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.


 A lack of QA suggests to me, a lack of concern for the interests of
 users.

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.

Now I'm not saying D doesn't need to improve its QA process -- that
would be quite welcome, in fact.  But don't be so naïve to imagine that
that alone is going to magically solve our problems. It may create new
ones instead.


 There are numerous research papers in this area, some of which I am in
 the process of reading, to gain a better understanding of QA in open
 source projects - and apparently it's a real issue of concern to those
 researching this topic.
 
 Anyway, as I go through these research papers, I suspect that it is
 unlikely they will conclude that bugs are just a part of software, and
 that's just life.. and least.. I hope not.

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. Turing-completeness comes at a cost, and part of
that cost is manifested in how a large software project becomes so
complex that no single person can possibly understand all of it, and
therefore any change that one makes is bound to cause unforeseen,
unexpected, or unintended consequences somewhere else in the system.
When you have a whole bunch of people contributing changes, the
existence of bugs is almost an inescapable fact.

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.


T

-- 
Philosophy: how to make a career out of daydreaming.

codephantom <me noyb.com> writes:

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.